This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: ulimit (2, -1)


Andreas Jaeger <aj@suse.de> writes:

> Can somebody please double check this with the standards?
> 
> If the patch is ok, I'll fix also the other ulimit implementations in
> glibc.  Ok to commit?

I've checked in a patch now.  Although I'm not entirely agreeing with
Mark's analysis (this specific problem is actually unspecified in the
standard since it's not overflowing in rlim_t) we have to handle
negative values appropriately.  The problem is that some 32bit
architectures support 4GB files and we simply have to ignore that the
ulimit() result is signed.  So, the compuations are carried out as if
unsigned and on overflow RLIM_INFINITY is used.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------


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