This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: All glibc machine maintainers: Is " RLIM_INFINITY as ((__rlim_t)-1)" OK?
- From: Chris Metcalf <cmetcalf at tilera dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library<libc-alpha at sourceware dot org>
- Date: Fri, 18 May 2012 21:35:14 -0400
- Subject: Re: RFC: All glibc machine maintainers: Is " RLIM_INFINITY as ((__rlim_t)-1)" OK?
- References: <CAMe9rOrVdp=Vq4RKX3Uh71E1+_UMJADgo0ahTaMBYgEj6OncBQ@mail.gmail.com>
On 5/18/2012 8:10 PM, H.J. Lu wrote:
>> It would be good to let all the machine maintainers verify that
>> > ((__rlim_t) -1) is really the same as ((unsigned long int)(~0UL)).
>> > I looked at all the headers and I'm pretty sure it's true, but
>> > I could have missed something.
> Please machine maintainers comment on this.
It seems that __RLIM_T_TYPE is ULONGWORD on all Linux platforms (it's SQUAD
on bsd4.4). And __RLIM64_T_TYPE is always UQUAD, so if you build with
-D_FILE_OFFSET_BITS=64, you'll get that for rlim_t.
Note that ((rlim_t) -1) is wrong for RLIM_INFINITY anyway; it would have to
be (((rlim_t) -1) >> 1), I think.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com