From owner-freebsd-bugs  Fri May 17 09:02:00 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA27062
          for bugs-outgoing; Fri, 17 May 1996 09:02:00 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA27052
          for <freebsd-bugs@freebsd.org>; Fri, 17 May 1996 09:01:55 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA28671; Sat, 18 May 1996 01:57:02 +1000
Date: Sat, 18 May 1996 01:57:02 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605171557.BAA28671@godzilla.zeta.org.au>
To: elrond2imladris.frmug.fr.net@memo.frmug.fr.net, freebsd-bugs@freebsd.org
Subject: Re: Bug found in getrlimit for 2.1R
Cc: roberto@keltia.freenix.fr
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>	I've found a bug in the getrlinit function(). Here is a small
>program to demonstrate this:

>...
>		printf("soft=%d\nhard=%d\n",(long)Lim.rlim_cur,Lim.rlim_max);
>...

>	This program outputs:

>-----
>soft=64
>hard=-1
>-----

>	And under gdb:

>-----
>Breakpoint 1, main () at toto.c:12
>(gdb) print Lim
>$1 = {rlim_cur = 0x0000000000000040, rlim_max = 0x7fffffffffffffff}
>-----

The hard limit is 0x7fffffffffffffff like gdb says it is.  This gets
truncated to -1 when it is converted to a long.

>...
>	But was unable to find it on my installation nor the second CD
>of 2.1R!

getrlimit is a system call so it is generated from some #defines in
/usr/src/lib/libc/sys.

>	I discovered this but while wriing a program working hard with
>sockets:

>-----
>getrlimit(RLINIT_NOFILE) returned garbage for rlim_max!!!
>Using arbitrary hard limit.

Several programs have problems with variables of type `long long'.

Bruce