[PATCH] C undefined behavior fix

[Florian Weimer]

Linus Torvalds <torvalds@transmeta.com> writes:

> What riles me is that people try to make _excuses_ for not following the
> standard, and claim that they do follow it, and try to lay the blame on
> gcc failures on the _users_.

We have a user failure here, haven't we?  It's documented that you
can't do what you are trying to do.

> If there are standards violations, at least be _honest_ about them.

There is no standards violation in this case.  We can simply say, "no
pointer value can be represented in any integer type, except 0" (a
perfectly valid approach), and all of a sudden, we have escaped to
undefined behavior:

       [#6]  Any  pointer type may be converted to an integer type.
       Except   as   previously   specified,    the    result    is
       implementation-defined.  If the result cannot be represented
       in the integer type, the behavior is undefined.

Of course, this is cheating, but you are cheating, too, with your
unsubstantiated claims of lacking standards conformance.

> I certainly think it is much better that you document places where
> the compiler doesn't follow the standard and be open about _why_ it
> doesn't, than try to bend the standard.

The C standard is not free documentation, and historically, only few
GCC users have access to it.  This is changing only slowly.  As a
result, documentation in terms of the C standard (and its violations)
is only of limited value, and C coders often barely know what is in
the standard, and what they can expect from the compiler.

But if we look back at the current problem and how it was presented
first (especially the proposed "fix"), I think we have got a more
fundamental problem: C code is considered to be correct if it compiles
to the expected machine code.  Unless a drastic change in attitude
takes place, we will get lost in the swamps at the borders of the C
standard over and over again, and there isn't much we can do about it.