This is the mail archive of the 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: 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 <> 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.

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