This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: signed is undefined and has been since 1992 (in GCC)
On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
Andrew Pinski <pinskia@physics.uc.edu> writes:
| On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
|
| > The attitude that "undefined behaviour" should be interpreted
| > as "we should not make things more useful when we can" is beyond
| > understanding.
|
| Then C/C++ aliasing rules go out the window really or maybe I
| misunderstand
| what you are trying to say?
yes, you misunderstand what I'm saying.
But you did not explain your full then, I still don't understand.
Here is the full quote from the C99 standard about what undefined
behavior:
1 behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation
or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a
diagnostic message).
3 EXAMPLE An example of undefined behavior is the behavior on integer
overflow.
See it even points out integer overflow as a good example. See also
how it says
the standard imposes no requirement, which means the compiler should be
able
to erase the hard drive each and every time you invoke undefined
behavior.
| And what about casting functions to a different function type and
| calling
| that, we just declared it as calling a trap in the last couple of
years.
That is a type constraint violation that leads to subtle runtime
errors, so we did actually improve things by catching (potential)
errors earlier.
So is wrapping, what is a different. If I multiply a large positive
number
by another large positive number, I will get an overflow, well since it
is undefined
I could get a positive number, a negative one, or a trap (or even my
hard drive erased
which is what I deserved).
For the concrete case at issue, if the hardware I'm writing the C/C++
programs for consistently displays modulo arithmetics for signed
integer type, Andrew can you tell me why GCC should deny me access
to that functionally where it actually can?
It does not, use -fwrapv if you want that behavior. GCC is not denying
you anything, at best it is giving you two different options, a fast
optimizing option and one where follows what you want.
"Denying" here means that
it does not give me access to that consistent hardware behaviour.
None of the items on the list you gave falls into that category.
Please, do remember that "undefined behaviour" is a catch-all basket
and two things in that basket are not necessarily "equally evil".
Well then why is there implementation defined behaviors then, it sounds
to me that you want it to be included there instead.
So,
please, do refrain from reasoning like "since we did X for Y and Y was
undefined behaviour, we should do the same for Z." "Undefined
behaviour" isn't a 0 or 1 thingy, even though it is about computers.
You need to evaluate them on case-by-case basis.
No, reread what the standard says we don't need to evaluate them case
by case, that
is what implementation defined behavior is for. Maybe this should have
been
made that but it was not. So file a DR report for it instead of saying
GCC should do
something when it is already doing what the standard says it can do.
-- Pinski