Re: Subtle error defining VALMASK?

[Paul Eggert <eggert@cs.ucla.edu>]

Dmitry Antipov wrote:
> In:
>
> #define VALMASK_val (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
>
> shouldn't it be
>
> #define VALMASK_val (USE_LSB_TAG ? - (1L << GCTYPEBITS) : VAL_MAX)
>
> or, if --with-wide-int on a 32-bit system:
>
> #define VALMASK_val (USE_LSB_TAG ? - (1LL << GCTYPEBITS) : VAL_MAX)

There's no error here.  All three definitions are equivalent because - 
(1 << GCTYPEBITS) equals -8, which sign-extends to the width of VAL_MAX. 
  When it doesn't matter, it's better to avoid length suffixes on 
integer constants.

There is another programming style, where authors take care to write 
exact suffixes on constants, e.g., 'lseek (fd, 0L, SEEK_SET)' when 
lseek's 2nd argument is 'long'.  In the old days before function 
prototypes this style was often necessary but that need went away long 
ago, and nowadays this other style is typically more trouble than it's 
worth.  For example, the 'lseek' call would be "wrong" now because 
lseek's argument type was changed from 'long' to 'off_t', and so a 
maintainer would have to change the call to 'lseek (fd, (off_t) 0, 
SEEK_SET)', whereas the simpler style 'lseek (fd, 0, SEEK_SET)' would 
survive the API change without needing maintenance.