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 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |