i386/57783: UINT32_MAX is missing from FreeBSD 4.X

[Bruce Evans]

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