Re: Serious code generation/optimisation bug (I think)

[Andrew Haley <aph at redhat dot com>]

Zoltán Kócsi wrote:
> On Tue, 27 Jan 2009 07:08:51 -0500
> Robert Dewar <dewar@adacore.com> wrote:
>
>> James Dennett wrote:
>>
>>> I don't know how much work it would be to disable this optimization
>>> in gcc.
>> To me, it is always troublesome to talk of "disable this optimization"
>> in a context like this. The program in question is not C, and its
>> semantics cannot be determined from the C standard. If the appropriate
>> gcc switch to "disable" the optimization is set, then the status of
>> the program does not change, it is still undefined nonsense. Yes, it
>> may happen to "work" for some definition of "work" that is in your
>> mind, but is not defined or guaranteed by any coherent language
>> definition. It seems worrisome to be operating under such
>> circumstances, so surely the best advice in a situation like
>> this is to fix the program.
>
> I don't mean to complain, but I happen to work with embedded
> systems.  I program them in C, or at least in a language that uses
> the syntactic elements of C. While it might not be a C program and
> is utter nonsense from a linguistic view, in the embedded world
> dereferencing a NULL pointer is often legal and actually
> unavoidable.

No, that's not true: accessing memory at address zero may be necessary,
but that is not the same as dereferencing a NULL pointer.  This may
sound like a minor and pedantic point, but I don't think it is: it goes
to the very core of this misunderstanding.

> Many embedded systems run on CPUs without MMU and I'd dare to state
> that there are many more of these lesser beasts out there than big
> multicore, superscalar CPUs with paged MMUs and vector processing
> units and FPUs. Now on many of these at location 0 you find a vector
> table or memory mapped registers or simple memory or even the
> dreaded zero-page where you can do things that you can't do anywhere
> else. On every one of those chips it is legal to dereference a NULL
> pointer as long as you have the notion of a pointer being an address
> of something.

If it's an embedded system, and your program is tied to particular
hardware with system data at address zero, you might as well access
that data with an asm; that's not going to reduce portability any.

> I openly admit that the test case was sloppy (and admitted it in my
> OP).  I do accept that due to the elevation of the C language from
> the low level system programming language it used to be to the
> linguisticly pure high-level object oriented metalanguage that C-99
> apparently is, dereferencing a NULL pointer became meaningless
> nonsense these days.

No, this is since C90; nothing has changed in this area.  NULL
doesn't mean "address 0", it means "nothing".  The C statement

  if (ptr)

doesn't mean "if ptr does not point to address zero", it means "if ptr
points to something".

> However, I'd like to point out one thing: the compiler is there to
> help the programmer. Derefencing a NULL pointer might be a bad thing
> on one system and perfectly normal on others.

> From a C language standard purist point of view such code might be
> nonsense, but chances are that you own and use some gadget every day
> that was programmed by such low-life engineers like me who live in
> those by-gone days where a pointer held a memory address and work
> with chips where at address 0 there are some useful things.

I think you perhaps need to be a little less patronizing.  Many of us,
myself included, have done a great deal of embedded programming and we
know what the issues are.  You have written an incorrect program, and
you now know what was incorrect about it.

> So, pretty please, when the compiler detects that a language
> resembling to, but not really C is used and removes assumedly
> (albeit unprovenly) superfluos chunks of code to purify the
> misguided programmer's intent, could it please at least send a
> warning?

In practice that's a lot harder than you might think.  If we were to
issue a warning for every transformation we made based on the
semantics of the C language I'm sure people would complain.  "You
can't dereference a NULL pointer" is a fundamental part of the
language.

Andrew.