[PATCH] C undefined behavior fix
Linus Torvalds
torvalds@transmeta.com
Fri Jan 4 16:26:00 GMT 2002
On Sat, 5 Jan 2002, Florian Weimer wrote:
> Linus Torvalds <torvalds@transmeta.com> writes:
>
> > To paraphrase:
> > Two implementation-defines does not make a undefine.
>
> I don't think you can assume that an implementation-defined pointer
> value can be safely dereferenced, without triggering undefined
> behavior.
You cannot assume that, of course. Implementation-defined means that you
can only assume it when _given_ the actual definition of the
implementation, and only for that implementation..
But implementation-defined does mean that the implementation has to say
what the behaviour (the standard calls it "choices") of the cast is.
Gcc sidesteps it by avoiding to say what the behaviour is. I even
understand _why_ gcc sidesteps it, and I could even buy into an argument
that just says "gcc is currently flawed at a lower level and cannot
reasonably do what you ask for", as long as it's admitting that gcc
doesn't follow the standard.
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_.
If there are standards violations, at least be _honest_ about them.
> > Yes, gcc forgets about "what is a pointer" when it gets to the RTL layer.
> > Yes, that means that alias analysis at that level simply is not valid. But
> > no, that does not mean that you can avoid the standard.
>
> Why can't we simply break the standard? Other people do it all the
> time.
Now you're _really_ talking about "two wrongs make a right", and hey,
maybe it's a valid argument. 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.
Linus
More information about the Gcc
mailing list