Null references redux

[Denis Koroskin]

On Mon, 28 Sep 2009 01:31:44 +0400, Jeremie Pelletier <jeremiep at gmail.com>  
wrote:

> Andrei Alexandrescu wrote:
>> Jeremie Pelletier wrote:
>>>> Is this Linux specific? what about other *nix systems, like BSD and  
>>>> solaris?
>>>
>>> Signal handler are standard to most *nix platforms since they're part  
>>> of the posix C standard libraries, maybe some platforms will require a  
>>> special handling but nothing impossible to do.
>>  Let me write a message on behalf of Sean Kelly. He wrote that to  
>> Walter and myself this morning, then I suggested him to post it but  
>> probably he is off email for a short while. Hopefully the community  
>> will find a solution to the issue he's raising. Let me post this:
>>  ===================
>> Sean Kelly wrote:
>>  There's one minor problem with his code.  It's not safe to throw an  
>> exception from a signal handler.  Here's a quote from the POSIX spec at  
>> opengroup.org:
>>  "In order to prevent errors arising from interrupting non-reentrant  
>> function calls, applications should protect calls to these functions  
>> either by blocking the appropriate signals or through the use of some  
>> programmatic semaphore (see semget() , sem_init() , sem_open() , and so  
>> on). Note in particular that even the "safe" functions may modify  
>> errno; the signal-catching function, if not executing as an independent  
>> thread, may want to save and restore its value. Naturally, the same  
>> principles apply to the reentrancy of application routines and  
>> asynchronous data access. Note thatlongjmp() and siglongjmp() are not  
>> in the list of reentrant functions. This is because the code executing  
>> after longjmp() and siglongjmp() can call any unsafe functions with the  
>> same danger as calling those unsafe functions directly from the signal  
>> handler. Applications that use longjmp() andsiglongjmp() from within  
>> signal handlers require rigorous protection in order to be portable."
>>  If this were an acceptable approach it would have been in druntime  
>> ages ago :-)
>> ===================
>>    Andrei
>
> Yes but the segfault signal handler is not made to design code that can  
> live with these exceptions, its just a feature to allow segfaults to be  
> sent to the crash handler to get a backtrace dump. Even on windows while  
> you can recover from access violations, its generally a bad idea to  
> allow for bugs to be turned into features.
>
> Jeremie

Isn't this reason alone strong enough to encourage use of non-null  
references?
And to implement them, since we don't the feature currently.