Re: SIZE_MAX

[Bruno Haible]

Hi Simon,

> > This would cause problems in libintl. The intl/ directory, when shipped
> > as part of a package that used gettextize, should not create its own copy
> > of stdint.h.
> 
> Btw, why not?  It seems it could create it under, say, intl/gl/

It could, certainly. But packages that include the intl/ subdirectory
should not be punished with lots of configure tests.

Also, this mode of shipping libintl should probably go away. It's so much
better to use it as a shared library. Therefore I don't want to spend much
time on autoconfiguration changes of intl/.

> > vasnprintf.c, which
> > depends on xsize.h, which needs a definition of SIZE_MAX. For this reason,
> > xsize.h arranges to get a correct SIZE_MAX in the cheapest possible way.
> 
> Ok, that makes sense.  I note that xsize.h does not include size_max.h.
> Should it?  Perhaps size_max.h does not make sense.

xsize.h contains the equivalent of size_max.h inlined:

  /* Get SIZE_MAX.  */
  #include <limits.h>
  #if HAVE_STDINT_H
  # include <stdint.h>
  #endif

Hard to say whether size_max.h is still worth it, except for the good
comments...

> How about clarifying the intentions behind the size_max module a bit
> better?  It seems most applications will want to include stdint.h and
> depend on the stdint gnulib module, rather than using the gnulib
> size_max module.

Exactly, right. The size_max.h file is from 2005, and since 2006 we have
a working <stdint.h> replacement, so most modules meanwhile rely on that.

Bruno