Re: [PATCH] diffseq: don’t assume integers lack padding

[Bruno Haible]

> Why this? What was wrong with the previous formula
> 
>   #define OFFSET_MAX \
>     ((((OFFSET)1 << (sizeof (OFFSET) * CHAR_BIT - 2)) - 1) * 2 + 1)
> 
> (OFFSET being a signed type)?

The same formula is being used in
lib/intprops.h:50:        : ((((t) 1 << (TYPE_WIDTH (t) - 2)) - 1) * 2 + 1)))
m4/longlong.m4:34:                          (1LL << (sizeof (long long int) * 
CHAR_BIT - 2))
m4/mktime.m4:223:                : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT 
- 2)) - 1)
m4/nanosleep.m4:59:                  : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) 
- 1) * 2 + 1)))
m4/stdint.m4:167:        : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 
1)))

Also in the documentation [1] we write
  "Gnulib code makes the following additional assumptions: 
   ...
   There are no “holes” in integer values: all the bits of an integer
   contribute to its value in the usual way."

Bruno

[1] 
https://www.gnu.org/software/gnulib/manual/html_node/Other-portability-assumptions.html