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.
