Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.

| 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. 

As a concrete case at point, the C++ committee just decided at the
last meeting in Norway to "upgrade" cast between void* and pointer to
function types from "undefined behaviour" to "conditionally supported"
-- and interestingly it led to vigurous request from library and
application programmers  that compilers do document what they are
doing in that area.  GCC had been a lead there.

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?  "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".  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.

-- Gaby