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

H.J. Lu hjl.tools@gmail.com
Sat May 19 03:37:00 GMT 2012


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.



More information about the Libc-alpha mailing list