Date: Mon, 20 Feb 1995 21:58:33 +1100 From: Bruce Evans <bde@zeta.org.au> To: davidg@Root.COM, wpaul@skynet.ctr.columbia.edu Cc: freebsd-hackers@FreeBSD.org Subject: Re: getrlimit()/setrlimit() strangeness Message-ID: <199502201058.VAA19821@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>getrlimit() reported that the soft file descriptor limit was 128 (which >>is correct) and that the hard limit was -1 (which is thoroughly bogus). > Actually, no, it isn't. -1 is RLIM_INFINITY which is documented in the >manual page. It simply means that there isn't a per-process hard limit. Since Actually, RLIM_INFINITY is ((u_quad_t)1 << 63) - 1), i.e., 0x7fffffffffffffffULL, which is a long way (in several directions at once :-) from the signed int -1. rlimits are (signed) quad_t's. There could easiliy be both sign extension and size bugs. You obviously have size bugs (printing rlimits using %d). The kernel has to be careful comparing the unsigned RLIM_INFINITY with signed rlimits. It actually does no such comparisions - it just forgets the signedness by assigning RLIM_INFINITY to quad_t's. RLIM_INFINITY should probably be defined as signed in the first place: ((quad_t)((u_quad_t)1 << 63) - 1)), i.e., 0x7fffffffffffffffLL It was signed in 1.1.5 (0x7fffffff). The u_quad_t cast is required because ((quad_t)1 << 63) and subtracting 1 from that both overflow. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502201058.VAA19821>