Date: Fri, 21 Oct 2016 20:37:47 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Colin Percival <cperciva@tarsnap.com> Cc: src-committers@FreeBSD.org, "svn-src-all\@freebsd.org" <svn-src-all@freebsd.org> Subject: Re: cvs commit: src/sys/sys _types.h resource.h Message-ID: <86wph1o8ec.fsf@desk.des.no> In-Reply-To: <01000157e3ac7982-b19e61c1-1619-44b1-88b5-3080d85e8d6d-000000@email.amazonses.com> (Colin Percival's message of "Thu, 20 Oct 2016 19:58:33 %2B0000") References: <200411081805.iA8I5hVK038813@repoman.freebsd.org> <01000157e3ac7982-b19e61c1-1619-44b1-88b5-3080d85e8d6d-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Colin Percival <cperciva@tarsnap.com> writes: > Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> writes: > > -typedef __int64_t __rlim_t; /* resource limit (XXX not uns= igned) */ > > +typedef __int64_t __rlim_t; /* resource limit - intentiona= lly */ > > + /* signed, because of legacy c= ode */ > > + /* that uses -1 for RLIM_INFIN= ITY */ > Is it time to drop compatibility for code which was "legacy" 12 years ago > in order to conform to the POSIX stipulation that rlim_t should be unsign= ed? Well, all of that code is already broken because I defined RLIM_INFINITY to 2^63-1 instead of 2^64-1. But we might as well align ourselves with the legacy code (and with other OSes), as the consequences of changing RLIM_INFINITY are mostly cosmetic: an older ulimit on a newer kernel (or the other way around) will print a very large number instead of "unlimited", and if an older binary sets a limit to RLIM_INFINITY on a newer kernel (or the other way around) the kernel will spend a little extra time checking limits which will never be reached anyway. This will allow us to eliminate a certain amount of code (e.g. in procfs and the Linuxulator) that translates back and forth between our current RLIMIT_INFINITY and (int64_t)-1 / ~0UL. DES -- Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86wph1o8ec.fsf>