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?
On 5/18/2012 10:47 PM, H.J. Lu wrote:
> On Fri, May 18, 2012 at 6:35 PM, Chris Metcalf <cmetcalf@tilera.com> wrote:
>> 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.
>>
> The current one has
>
> #ifndef __USE_FILE_OFFSET64
> # define RLIM_INFINITY ((unsigned long int)(~0UL))
> #else
> # define RLIM_INFINITY 0xffffffffffffffffuLL
> #endif
>
>
> Why ((rlim_t) -1) is wrong? BTW, x32 rlim_t is 64-bit.
Yes, I didn't realize it could be signed or unsigned depending on platform,
32- vs 64-bit API in use, etc. (that's amazingly crazy for an API). You're
right that on Linux, only alpha, sparc, and mips use the signed variant
with the ">> 1". Since the generic bits/resource.h effectively has the ">>
1" definition I assumed that's what all platforms really wanted, and missed
the override in sysdeps/unix/sysv/linux.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com