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 document the types of standard typedefs


On Sunday 26 February 2012 21:55:55 Paul Eggert wrote:
> On 02/26/2012 04:31 PM, Joseph S. Myers wrote:
> >  @deftp {Data Type} mode_t
> > 
> > -This is an integer data type used to represent file modes.  In the
> > -GNU system, this is equivalent to @code{unsigned int}.
> > +This is an integer data type used to represent file modes.
> > 
> >  @end deftp
> 
> It's helpful for application writers to know that on GNU systems
> mode_t is no narrower than int (so that the usual stdarg code works with
> mode_t values), and it might be helpful to know that mode_t is unsigned
> (so that app writers need not worry about undefined behavior
> shifting mode_t values).  So I suggest saying that on GNU systems,
> mode_t is an unsigned type no narrower than unsigned int.

i think it's unhelpful to encourage people to make assumptions about the sizes 
of mode_t.  i've been bitten by that when i tried something naÃve like:
	mode_t m;
	scanf("%u", &m);
and %u ends up writing more bytes than mode_t is taking up on the stack.

doesn't describing it as "an integer data type" handle your concerns about 
shift behavior ?

> >  @deftp {Data Type} ino_t
> >  This is an arithmetic data type used to represent file serial numbers.
> >  (In Unix jargon, these are sometimes called @dfn{inode numbers}.)
> > 
> > -In the GNU system, this type is equivalent to @code{unsigned long int}.
> 
> nlink_t is similar, except there's no guarantee that it's
> no narrower than 'int'.

and it's not unusual for it to be a short ...
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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