This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RFC: All glibc machine maintainers: Is " RLIM_INFINITY as ((__rlim_t)-1)" OK?
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 18 May 2012 17:10:20 -0700
- Subject: RFC: All glibc machine maintainers: Is " RLIM_INFINITY as ((__rlim_t)-1)" OK?
On Fri, May 18, 2012 at 4:07 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I think it warrants a comment that the purpose of all the unions is to have
> the kernel-compatible layout while keeping the API type as 'long int', and
> among machines where __syscall_slong_t is not 'long int' this only does the
> right thing for little-endian ones (but the only such case qualifies).
Like this?
/* Structure which says how much of each resource has been used. The
purpose of all the unions is to have the kernel-compatible layout
while keeping the API type as 'long int', and among machines where
__syscall_slong_t is not 'long int', this only does the right thing
for little-endian ones, like x32. */
> 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.
> I think we may also still be waiting for anyone to object to the notion of
> using anonymous __extension__ union in public header files.
>
I will wait until next Tuesday.
Thanks.
--
H.J.