This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Don't discuss details of what type size_t might be typedefed to
On Sun, 26 Feb 2012, Paul Eggert wrote:
> First, although the C standard allows size_t to be
> 'unsigned short' or even 'unsigned char', glibc doesn't
> now and is unlikely ever port to any such host. It'd be a pain for
> application writers to worry about such (theoretical) platforms,
> so it's helpful for the manual to say that size_t is no narrower
> than 'unsigned int'.
That's about va_arg?
> Second, the C standard recommends that size_t shouldn't have
> an integer conversion rank greater than 'long' unless it's necessary.
> For application writers' benefit, the glibc manual should document
> the platforms where it's really necessary for size_t to be wider than
> 'unsigned long'. Currently this is the empty set for glibc, and the
> manual should document that.
Why would an application writer writing specifically for GNU systems care
about that? They can assume C99 library facilities such as printf %zu and
uintmax_t. Assuming it's no wider than long is more a matter of C90
compatibility, and details of that seem more in scope for the GNU Coding
Standards.
Would something like "On systems using the GNU C Library, this will be
@w{@code{unsigned int}} or @w{@code{unsigned long int}}." be sufficient?
In particular, do you agree that the discussion about redeclaring malloc,
and when it matters that two types of the same width are different, can be
removed?
--
Joseph S. Myers
joseph@codesourcery.com