On 09/11/15 13:42, Vincent Lefevre wrote: > On 2015-11-09 03:40:12 -0600, Segher Boessenkool wrote: >> On Mon, Nov 09, 2015 at 09:28:49AM +0100, Vincent Lefevre wrote: >>> On 2015-11-08 18:49:46 -0600, Segher Boessenkool wrote: >>>> On Mon, Nov 09, 2015 at 01:27:34AM +0100, Vincent Lefevre wrote: >>>>>> Why not simply: >>>>>> unsigned y = x; >>>>>> return y*y*y; >>>>>> ? This is an example where defined behavior is so easy to get... >>>>> >>>>> But what if the result of y*y*y (an unsigned int) does not fit in >>>>> an int? >>>> >>>> That is implementation-defined. not undefined (6.3.1.3); GCC documents >>>> it like this: >>>> >>>> For conversion to a type of width N, the value is reduced modulo >>>> 2^N to be within range of the type; no signal is raised. >>> >>> That's what GCC does, but what if the user uses another compiler >>> or GCC decides to change this behavior in the future? >> >> Then it is still not undefined behaviour. It can give different results >> of course. > > ... including a signal, which is not acceptable for the OP, if I > understand correctly ("we don't care about the result in such cases" > doesn't imply that the program may terminate immediately). > Correct. The ideal here is to get an /unspecified/ integer - without the risk of a trap or undefined behaviour. Implementation-defined behaviour that is known to be safe on gcc is a step forward - I am aware that the ideal here is not possible in standard and portable C. In this particular example, implementation-dependent behaviour is fine. But in some circumstances, unspecified behaviour /may/ be even better as it gives the compiler complete freedom for optimisation. Here the compiler is required to generate a specific result, as calculated using the implementation-specified rules.