[LTP] ulimit(2, -1) testcase

[Andreas J. <aj...@su...>]

Looking at LTP I noticed the following failure:
ulimit01    2  FAIL  :  ulimit(2, -1) returned 0

After checking with the other glibc developers, I do think the test is
wrong.

The Unix standard says:

} UL_SETFSIZE Set the file size limit for output operations of the process
} to the value of the second argument, taken as a long, multiplied by 512.
} If the result would overflow an rlim_t, the actual value set is
} unspecified. Any process may decrease its own limit, but only a process
} with appropriate privileges may increase the limit. The return value
} shall be the integer part of the new file size limit divided by 512.
} 
} [EINVAL] The cmd argument is not valid.

Ulrich Drepper mentioned:

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

glibc 2.2.5 will therefore not return a failure if ulimit (2, -1) is
run as root - or if RLIM_INFINITY was used before.

glibcs before 2.2.4 did not handle the overflow at all.

Btw. the README file in the LTP CVS archive still mentions the old SGI
email address and URL.  Could somebody grep through the sources and
fix everything?

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