Re: [PATCH] inttypes.h: imaxabs(3): Implement as a macro

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

On 9/13/22 13:27, Joseph Myers wrote:

> C2x allows integer types wider than intmax_t in certain cases....
> (Changing intmax_t would be a pain because of the very large
> number of printf-like functions in glibc, all of whose ABIs involve
> intmax_t.)

It would indeed be a pain. However, the possibility of 
wider-than-intmax_t types is potentially even a much greater pain for 
user code. It's common, for example, for user code to have functions 
like this:

   int
   print_offset (off_t offset)
   {
     intmax_t off = offset;
     return printf ("%jd", off);
   }

Unfortunately, code like this would not work if off_t were wider than 
intmax_t. This is fresh in my mind as I recently added code like the 
above to paxutils, replacing older, pre-C99 code that converted off_t to 
strings by hand. Was I mistaken? 
<https://git.savannah.gnu.org/cgit/paxutils.git/commit/?id=2bf63fcba72c4f4bc54a4caf53d7923c1f9f174f>

Is it safe to assume that standard types like off_t are no wider than 
intmax_t? If so, this should be documented explicitly somewhere in the 
glibc manual. If not, user code would be in so much hurt that it really 
ought to be glibc's job to widen intmax_t to be at least as wide as 
standard types, as painful as that widening might be.