On 2018-07-19 16:10:35 +0200, Joerg Schilling wrote: > /* > * These macros may not work on all platforms but as we depend > * on two's complement in many places, they do not reduce portability. > * The macros below work with 2s complement and ones complement machines. > * Verify with this table... > * > * Bits 1's c. 2's complement. > * 100 -3 -4 > * 101 -2 -3 > * 110 -1 -2 > * 111 -0 -1 > * 000 +0 0 > * 001 +1 +1 > * 010 +2 +2 > * 011 +3 +3 > * > * Computing -TYPE_MINVAL(type) will not work on 2's complement machines > * if 'type' is int or more. Use: > * ((unsigned type)(-1 * (TYPE_MINVAL(type)+1))) + 1; > * it works for both 1's complement and 2's complement machines. > */ > #define TYPE_ISSIGNED(t) (((t)-1) < ((t)0)) > #define TYPE_ISUNSIGNED(t) (!TYPE_ISSIGNED(t)) > #define TYPE_MSBVAL(t) ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) > #define TYPE_MINVAL(t) (TYPE_ISSIGNED(t) \ > ? TYPE_MSBVAL(t) \ > : ((t)0)) > #define TYPE_MAXVAL(t) ((t)(~((t)0) - TYPE_MINVAL(t))) > > It worked for 20 years without problems but recently some compilers > decided to issue a warning.
The problem is not just the warning. If t is signed, ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) will yield undefined behavior due to overflow. This means that compilers may generate code that shows a behavior different from what you expect. Not just recent compilers. Compilers could already do this 20 years ago without a warning. Perhaps some did. Perhaps some users got crashes and other erratic behavior due to that, but did not know the cause or did not notice. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
