From nobody@FreeBSD.ORG  Thu Oct 12 23:22:53 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 5CAB437B502; Thu, 12 Oct 2000 23:22:53 -0700 (PDT)
Message-Id: <20001013062253.5CAB437B502@hub.freebsd.org>
Date: Thu, 12 Oct 2000 23:22:53 -0700 (PDT)
From: jau@iki.fi
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: RLIM_INFINITY definition is apparently wrong

>Number:         21948
>Category:       kern
>Synopsis:       RLIM_INFINITY definition is apparently wrong
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 12 23:30:00 PDT 2000
>Closed-Date:    Wed Nov 21 10:20:05 PST 2001
>Last-Modified:  Wed Nov 21 10:35:28 PST 2001
>Originator:     Jukka A. Ukkonen
>Release:        3.5.1
>Organization:
SysOpen Ltd. / Finland
>Environment:
FreeBSD mjolnir.thunderbolt.fi 3.5.1-RELEASE FreeBSD 3.5.1-RELEASE #1: Sun Oct  8 20:16:47 EET DST 2000     jau@mjolnir.thunderbolt.fi:/usr/src/sys/compile/Mjolnir  i386

>Description:
RLIM_INFINITY is currently defined as follows...

#define RLIM_INFINITY   ((rlim_t)(((u_quad_t)1 << 63) - 1))

This is apparently wrong, because using an unsigned quad length
integer to represent the value hints that the intended bit pattern
to represent infinity is all 64 bits one, 0xFFFFFFFFFFFFFFFF.
The current definition makes the pattern anyhow 0x3FFFFFFFFFFFFFFF,
which does not require an unsigned type at all.

>How-To-Repeat:

>Fix:
Either 
#define RLIM_INFINITY   ((rlim_t)((u_quad_t) ~0ULL))
or
#define RLIM_INFINITY   ((rlim_t)(~ (u_quad_t) 0))


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: jau@iki.fi
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/21948: RLIM_INFINITY definition is apparently wrong
Date: Fri, 13 Oct 2000 21:33:30 +1100 (EST)

 On Thu, 12 Oct 2000 jau@iki.fi wrote:
 
 > >Description:
 > RLIM_INFINITY is currently defined as follows...
 > 
 > #define RLIM_INFINITY   ((rlim_t)(((u_quad_t)1 << 63) - 1))
 > 
 > This is apparently wrong, because using an unsigned quad length
 > integer to represent the value hints that the intended bit pattern
 > to represent infinity is all 64 bits one, 0xFFFFFFFFFFFFFFFF.
 > The current definition makes the pattern anyhow 0x3FFFFFFFFFFFFFFF,
 > which does not require an unsigned type at all.
 
 Actually, the current definition makes the bit pattern 0x7FFFFFFFFFFFFFFF.
 This doesn't require an unsigned type, but one more than it does (on most
 machines), since subtracting one from the value with bit pattern
 0x8000000000000000 would overflow on most machines.
 
 Bruce
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sat Nov 17 11:45:52 PST 2001 
State-Changed-Why:  

What was the conclusion here? Is this a bug or not? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21948 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Wed Nov 21 10:20:05 PST 2001 
State-Changed-Why:  

The submitter agrees that due to the current type of rlim_t (quad_t), 
the present value of RLIM_INFINITY is reasonable (it is defined as 
0x7fffffffffffffff, the largest value representable by the type). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21948 
>Unformatted:
 X-Send-Pr-Version: www-1.0
 
 
