This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ulimit (2, -1)


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]