Date: Thu, 9 Oct 2003 01:20:21 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-i386@FreeBSD.org Subject: Re: i386/57783: UINT32_MAX is missing from FreeBSD 4.X Message-ID: <200310090820.h998KLt3070570@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/57783; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Ted Mittelstaedt <tedm@ipinc.net> 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. <limits.h> is not permitted to define UINT32_MAX. In C99, UINT32_MAX is only defined in <stdint.h> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310090820.h998KLt3070570>