Re: ulimit (2, -1)

[Andreas Jaeger <aj at suse dot de>]

Mark Brown <bmark@us.ibm.com> writes:

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

That's what I feared and why I asked for double checking with the
standards.

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

What handling would meet the standards?  And is -1 really an overflow?

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