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