Konstantin Belousov wrote, On 11/30/2013 13:56:
The compiler authors take the undefined part there as a blanket to perform
optimizations which are assuming that signed overflow cannot happen.

Personally, when I first heard about such assumptions, it was inspiring to 
write code in a way that automatically gives the compiler certain ``overflow 
cannot happer'' (for example, because the input values given are always small) 
hints, such as turning some uses of ``unsigned int'' (where a negative value 
logically doesn't make sense, such as in a size/length value) into ``signed 
int''. However, I quickly found that this way of thinking leads to 
counter-production: coding becomes slower, the resulting code becomes less 
readable, while the performance gain remains questionable. It would be much 
better if hints could be given to the compiler using assert() (which would have 
effect even in non-debug mode). How do others feel?

Konstantin Belousov wrote, On 12/01/2013 08:59:
It is written in C, but no useful program can be written in the pure
standard C.  We must rely on the assumptions about underlying architecture,
and compiler must provide sane access to the features of the underlying
architecture to be useful.

But what behavior do you want for signed arithmetic? Modular, saturating, or some other? 
And how do you signal that? Or maybe you just want to check for (signed/unsigned) integer 
overflow (which can't be done "cleanly and efficiently" in C), in which case 
someone should write a check_add_overflow() function...
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to