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

[David Miller]

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.