From owner-freebsd-hackers Mon Feb 20 03:00:37 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA06596 for hackers-outgoing; Mon, 20 Feb 1995 03:00:37 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA06548 for ; Mon, 20 Feb 1995 03:00:21 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA19821; Mon, 20 Feb 1995 21:58:33 +1100 Date: Mon, 20 Feb 1995 21:58:33 +1100 From: Bruce Evans Message-Id: <199502201058.VAA19821@godzilla.zeta.org.au> To: davidg@Root.COM, wpaul@skynet.ctr.columbia.edu Subject: Re: getrlimit()/setrlimit() strangeness Cc: freebsd-hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >>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