Date: Fri, 21 Oct 2016 22:02:41 +0000 From: Colin Percival <cperciva@tarsnap.com> To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no> 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: <01000157e944783d-5458f67c-26df-45fc-b823-c9ffdcfeeaab-000000@email.amazonses.com> In-Reply-To: <86wph1o8ec.fsf@desk.des.no> References: <200411081805.iA8I5hVK038813@repoman.freebsd.org> <01000157e3ac7982-b19e61c1-1619-44b1-88b5-3080d85e8d6d-000000@email.amazonses.com> <86wph1o8ec.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/21/16 11:37, Dag-Erling Smørgrav wrote: > Colin Percival <cperciva@tarsnap.com> writes: >> Dag-Erling Smørgrav <des@freebsd.org> writes: >>> -typedef __int64_t __rlim_t; /* resource limit (XXX not unsigned) */ >>> +typedef __int64_t __rlim_t; /* resource limit - intentionally */ >>> + /* signed, because of legacy code */ >>> + /* that uses -1 for RLIM_INFINITY */ >> 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 unsigned? > > 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 [...] I wasn't talking about the value of RLIM_INFINITY, but rather about whether rlim_t should be signed or unsigned. Right now it is signed; but POSIX says it should be unsigned, and most other OSes follow POSIX's mandate here. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01000157e944783d-5458f67c-26df-45fc-b823-c9ffdcfeeaab-000000>