On 10/21/16 11:37, Dag-Erling Smørgrav wrote: > Colin Percival <cperc...@tarsnap.com> writes: >> Dag-Erling Smørgrav <d...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
