Re: removing stdint's dependency on wchar

[Paul Eggert]

On 02/18/2011 03:25 AM, Bruno Haible wrote:

> it's easy to remember: "I want a working stdint.h -
> so I need module stdint  or stdint-posix if that exists)".

It'd be nice if it were that easy, but unfortunately it's not.

In the old days, when one needed a working uint32_t, one
would just invoke AC_TYPE_UINT32_T or something like that.
There were problems with that approach, but it had one
major advantage: one didn't drag in all sorts of tests
for things like wint_t that one doesn't need.

I'd like to resurrect that old advantage, if possible.
Gnulib deservedly has the reputation of too many dependencies,
and this is inhibiting its use in other projects (not just
Emacs).  If we can break the dependencies at a relatively
small cost, we should do that.

One way to attack this particular issue would be to have
a new module, uint32_t say, that just supplies  the
uint32_t feature.  That is, it arranges for a stdint.h that
defines uint32_t, but the stdint.h might not be good for
anything else.

That would be overkill, though.  The stdint module defines
waaayy too many features and it would be a big pain to write
a separate module for each one.  And it's not like stdint is
unique in this respect; we have other modules such as stdlib
that define many features.  What we've done in the past is
take a pragmatic approach: we support all the features that
are generally needed by a stdlib's users or are easy to
support, but when there's a definite cost for a feature that
hardly anybody uses, we partition it off into an extra module.

That's what's needed for stdint.  Hardly anybody needs its
WINT_MAX and WCHAR_MAX features, so it makes sense to
partition them off.  We don't insist that stdbool mimic
C99 bool exactly, only "well enough"; and similarly we don't
need to insist that stdint mimic C99 stdint.h exactly.