ulimit (2, -1)

[Mark Brown]

Andreas Jaeger wrote on 24/09/01 12:02 PM:

> 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.
>> 
>> 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".
> What handling would meet the standards?  And is -1 really an overflow?

The last question is a good one.

I'm looking at the following text in the spec:
---
As all return values are permissible in a successful situation, an
application wishing to check for error situations should set errno to
0, then call ulimit( ), and, if it returns -1, check to see if errno
is non-zero.
---

This says that -1 can be a permissable outcome, since some values
in rlim_t (an unsigned long) may produce a negative value in the
signed long that is the return value. This says to me that
[the value represented by -1] is not necessarily an invalid
input. 

Of course, if this represents an _increase_ to an application's
limits, the value can be rejected EPERM if the proces doesn't
have priveleges.


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