Date: Fri, 13 Feb 2015 20:37:18 +0300 From: Andrey Chernov <ache@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>, Pedro Giffuni <pfg@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r278634 - head/lib/libc/gen Message-ID: <54DE364E.4060203@freebsd.org> In-Reply-To: <20150214005543.X2210@besplex.bde.org> References: <201502122107.t1CL7gaO004041@svn.freebsd.org> <BF5F2941-52F5-41A4-8723-E316919718EE@FreeBSD.org> <54DD2A87.2050008@FreeBSD.org> <9A683D99-C1E9-4736-982C-69F583D3A40D@FreeBSD.org> <20150213172738.C1007@besplex.bde.org> <54DDABF2.9000201@freebsd.org> <54DDAEF6.3060900@freebsd.org> <20150214005543.X2210@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.02.2015 17:29, Bruce Evans wrote:
>> if (arg < 0) {
>> errno = EINVAL;
>> return (-1);
>> }
>
>
> This is reasonable, but not encouraged by the API or compatible with
> what setrlimit() does with negative args. (setrlimit() still uses
> my hack from 1994, of converting negative args to RLIM_INFINITY. In
> 4.4BSD, it doesn't even check for negative args, and mostly stores
> them unchanged; then undefined behaviour tends to occur when the
> stored values are used without further checking.)
This hack should be removed from setrlimit() to catch real error.
Any syscall should do basic arguments validation.
This is true about ulimit() too, so it is not a syscall. If overflow
happens before passing arg, it is better to report it than to convert
blindly to RLIM_INFINITY.
Somebody may decrement long limit value by fixed chunks and go beyond
zero. I.e. situation is completely opposite: he means 0 limit, but you
set it to INFINITY. So it is always better to report error to leave
caller deal with it. If he needs a bigger than long limit, he should use
setrlimit() directly, not ulimit().
--
http://ache.vniz.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54DE364E.4060203>