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: David Miller <davem at davemloft dot net>
- To: hjl dot tools at gmail dot com
- Cc: roland at hack dot frob dot com, libc-alpha at sourceware dot org
- Date: Fri, 18 May 2012 23:33:22 -0400 (EDT)
- Subject: Re: RFC: All glibc machine maintainers: Is " RLIM_INFINITY as((__rlim_t) -1)" OK?
- References: <CAMe9rOrVdp=Vq4RKX3Uh71E1+_UMJADgo0ahTaMBYgEj6OncBQ@mail.gmail.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 18 May 2012 17:10:20 -0700
> On Fri, May 18, 2012 at 4:07 PM, Roland McGrath <roland@hack.frob.com> 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.
FWIW, Sparc overrides these definitions so should not be influenced
by this change.
In fact on 32-bit with __USE_FILE_OFFSET64 not defined, sparc defines
it as:
# define RLIM_INFINITY ((long int)(~0UL >> 1))
and I notice that i386 has bit of code encapsulating the rlimit calls
which translates between RLIM_INFINITY and "RLIM_INFINITY >> 1" in
certain situations.
Finally, Sparc didn't always get these values right, see:
commit 9c96ff23858b0759e12ad69e3c4599931c90bee8
Author: David S. Miller <davem@davemloft.net>
Date: Sun Aug 14 04:07:50 2011 -0700
* sysdeps/unix/sysv/linux/sparc/bits/resource.h (RLIM_INFINITY,
RLIM64_INFINITY): Fix 64-bit values for 32-bit sparc.