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)


Ulrich Drepper <drepper@redhat.com> writes:

> 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.

sysdeps/unix/bsd/ulimit.c needs the same change.

I'll discuss this now with the LTP guys where the failure came from,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj


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