Andrew Pinski <[EMAIL PROTECTED]> 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
