This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]