ulimit (2, -1)
Mark Brown
bmark@us.ibm.com
Mon Sep 24 08:22:00 GMT 2001
Andreas Jaeger wrote on 22/09/01 8:43 AM:
> The following program:
> long int res = ulimit (2, -1);
> Res: 0, errno: Success
>
> which is wrong, setting the limit to -1 should IMO give an error. The
> problem is that in ulimit.c we tread the second argument as long int
> and assign it to:
> limit.rlim_cur = newlimit * 512;
> where rlim_cur is of type rlim_t which is unsigned long. Shouldn't we
> check for negative values and set errno to EINVAL in this case? I'm
> appending a patch.
Here is selected text of the standard:
-----
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.
----
So, you can't use EINVAL for a bad second argument.
But you *can* set the result to be what you consider correct upon
detecting something that would "overflow an rlim_t".
The suggested patch does not meet standards.
--
Mark S. Brown bmark@us.ibm.com
Senior Technical Staff Member 512.838.3926 T/L678.3926
IBM Corporation, Austin, Texas Mark Brown/Austin/IBM
More information about the Libc-hacker
mailing list