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