[PATCH] C undefined behavior fix
dewar@gnat.com
dewar@gnat.com
Fri Jan 4 17:04:00 GMT 2002
<<I believe that you're being uselessly pedantic here. "Implementation
defined", in terms of the way the C standard is written, means that it
does something reasonable and useful that will be documented. This is
opposed to "undefined" which could logically include things like
generating code that crashes.
>>
You must have a different copy of the standard than I have. I do not find
the requirement for "reasonable and useful" anywhere.
You say I am being pedantic, but it is Linus (and perhgaps you) that are
trying to argue from the standard. If you argue from the standard, you
MUST be pedantic, which in this context means following the wording of
the standard precisely.
Now if you want to be pragmatic, then fine, but please STOP appealing to
the standard, especially when the appeals are wrong and confused.
<<is intended to be an "out". But it seems to me that it doesn't work. We
are defining P2I(p) to preserve bits, and we are defining I2P(i) to
preserve bits. These two definitions, it seems to me, nail down the
definition of I2P(P2I(p)+offset). It simply is not mathematically
consistent to define two functions rigorously (three, counting the
addition, which does not overflow) and then claim that their composition
is undefined. That's nonsense, so Linus is right.
>>
No, it is not nonsense, the paragraph that you reject (I won't quote it
again) is PART of the definition, it is just as valid a part of the definition
as the statement about preserving bits. You want to pick and choose here and
reject the part of the definition you don't like, but you have no basis in
the standard, or for that matter elsewhere for doing this selection.
I really think that it is quite silly to try to argue your position from
the standard. Instead you should be trying to make a clear definition of
the semantics you want to see, and then making a pragmatic argument for
the desirability of these semantics.
More information about the Gcc
mailing list