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]

Re: RFC: All glibc machine maintainers: Is " RLIM_INFINITY as((__rlim_t) -1)" OK?


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.

-- 
H.J.


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