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