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