Re: Don't document the types of standard typedefs

[Paul Eggert <eggert at cs dot ucla dot edu>]

On 02/27/2012 05:48 AM, Joseph S. Myers wrote:
> Is this saying that any system on which mode_t does not have those 
> properties would never be considered a GNU system (as per 
> <http://sourceware.org/ml/libc-alpha/2012-02/msg00454.html>)?  Or should 
> we actually say that, whatever the underlying kernel interface, the GNU C 
> Library will provide an interface to applications with those properties 
> (various types on GNU/Linux were deliberately made wider than in the 
> kernel, for future-proofing)?  That is, "In the GNU C Library, this is an 
> unsigned type no narrower than @code{unsigned int}.".

As an application writer, I'd prefer the latter, if that's easy,
since it means my code would be portable to any glibc system,
not just any GNU system.  Similarly for ino_t etc.

>> 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?

va_arg, yes, but other things as well.  For example:

   size_t a = [whatever], b = [whatever];
   if (a + b < a)
     error ("size_t overflow");

doesn't work as expected if size_t is narrower than int.


> 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.

True, but for this particular item I was thinking about the fact that in
practice many (most?) GNU apps try to be portable to pre-C99 hosts,
and it's more convenient for them if they can assume
size_t is no wider than unsigned long.

> 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?

Sure, that's even stronger than what I suggested.

> 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?

Yes.