[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIZE_MAX
From: |
Bruno Haible |
Subject: |
Re: SIZE_MAX |
Date: |
Sun, 31 May 2009 20:03:46 +0200 |
User-agent: |
KMail/1.9.9 |
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