From owner-freebsd-i386@FreeBSD.ORG Thu Oct 9 01:20:23 2003 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BBEF16A4C0 for ; Thu, 9 Oct 2003 01:20:23 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 658ED43FB1 for ; Thu, 9 Oct 2003 01:20:22 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h998KMFY070572 for ; Thu, 9 Oct 2003 01:20:22 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h998KLt3070570; Thu, 9 Oct 2003 01:20:21 -0700 (PDT) (envelope-from gnats) Date: Thu, 9 Oct 2003 01:20:21 -0700 (PDT) Message-Id: <200310090820.h998KLt3070570@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Subject: Re: i386/57783: UINT32_MAX is missing from FreeBSD 4.X X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 08:20:23 -0000 The following reply was made to PR i386/57783; it has been noted by GNATS. From: Bruce Evans To: Ted Mittelstaedt Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/57783: UINT32_MAX is missing from FreeBSD 4.X Date: Thu, 9 Oct 2003 18:13:13 +1000 (EST) On Wed, 8 Oct 2003, Ted Mittelstaedt wrote: > >Description: > > A definition of UINT32_MAX is missing from /usr/include/machine/limits.h UINT32_MAX is part of C99, and most of C99 including this part is not supported in RELENG_4. > This is an obvious oversight as the manpage for arc4random() shows it > returning u_int32_t u_int32_t is not part of C99. It is the same as uint32_t if C99 is supported and uint32_t is supported. There are no U_FOOn_MAX macros corresponding to the u_fooN_t types, and such macros are mostly not needed since the maximums are easily calculated. (C99 needs them more because the maximums are not so easily calculated for implementation-defined types larger than long.) > I found a note on Usenet to the effect that this was (may have been?) > fixed in FreeBSD 5? Sort of. More parts of C99 including limits for fixed-width types are supported, but arc4random() is still documented to return u_int32_t so using UINT32_MAX with it is still an anachronism. > >How-To-Repeat: > > >Fix: > > I think that adding > > #define UINT32_MAX 0xffffffffU /* max value for an unsigned int */ > > to limits.h will fix this. This would add some bugs: - namespace pollution. is not permitted to define UINT32_MAX. In C99, UINT32_MAX is only defined in (and inttypes.h>). - the cloned comment is wrong in this context. - the U suffix is not quite right in this context. It is correct but redundant for UINT_MAX on 32-bit machines. I think it is wrong on machines with UINT32_MAX < INT_MAX. In current, all UFOO_MAX's are defined in MD files so that we don't have to worry about the delicate considerations needed to define them in an MI way using something like the above. > Note also that /usr/src/usr.bin/jot/jot.c uses the UINT32_MAX on line > number 280, but someone has replaced this with the actual constant. This is the correct fix in -current too. It avoids the anachronism. > (If jot.c is ever updated this may be a problem again) Not unless arc4random()'s interface is changed to return. 32 won't change, and hard-coding it in the name "UINT32_MAX" is little different from hard-coding it in "0xffffffff". Bruce