Date: Sat, 18 May 1996 01:57:02 +1000 From: Bruce Evans <bde@zeta.org.au> To: elrond2imladris.frmug.fr.net@memo.frmug.fr.net, freebsd-bugs@freebsd.org Cc: roberto@keltia.freenix.fr Subject: Re: Bug found in getrlimit for 2.1R Message-ID: <199605171557.BAA28671@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605171557.BAA28671>