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