D - Unsafe and doomed

deadalnix deadalnix at gmail.com
Mon Jan 6 07:01:35 PST 2014


On Monday, 6 January 2014 at 02:03:03 UTC, Walter Bright wrote:
> On 1/5/2014 4:20 PM, deadalnix wrote:
>> On Monday, 6 January 2014 at 00:13:19 UTC, Walter Bright wrote:
>>> I'd still like to see an example, even a contrived one.
>>
>> void foo(int* ptr) {
>>     *ptr;
>>     if (ptr is null) {
>>         // do stuff
>>     }
>>
>>     // do stuff.
>> }
>>
>> The code look stupid, but this is quite common after a first 
>> pass of
>> optimization/inlining, do end up with something like that when 
>> a null check if
>> forgotten.
>
> The code is fundamentally broken. I don't know of any 
> legitimate optimization transforms that would move a 
> dereference from after a null check to before, so I suspect the 
> code was broken before that first pass of optimization/inlining.
>

I know. But his code will behave in random ways, not instant 
fail. This example show that the instant fail approach you seem 
to like is inherently flawed.

> If you're writing code where you expect undefined behavior to 
> cause a crash, then that code has faulty assumptions.
>
> This is why many languages work to eliminate undefined behavior 
> - but still, as a professional programmer, you should not be 
> relying on undefined behavior, and it is not the optimizer's 
> fault if you did. If you deliberately rely on UB (and I do on 
> occasion) then you should be prepared to take your lumps if the 
> compiler changes.

Are you saying that dereferencing null must be undefined 
behavior, and not instant failure ? That contradict the position 
you gave before.


More information about the Digitalmars-d mailing list