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