glibc sysdeps/posix/tempname.c: uint64_t problem on non-glibc hosts

[Paul Eggert]

> From: Jim Meyering <address@hidden>
> Date: 16 Mar 2001 10:28:38 +0100
> 
> I've received a report of a build failure on Ultrix due to lack of
> the uint64_t type.  That type is used in tempname.c, but there is
> no test that might define the type on systems that don't have it.

That's a problem, because some old hosts max out at 32-bit integers.
(Also, strictly speaking, C99 doesn't require int64_t, though I don't
expect us to encounter C99 GNU porting targets without int64_t.)

> What do you think about using uintmax_t instead?

Yes, for this particular case I think even a 32-bit uintmax_t is an
acceptable substitute.  Here's a proposed patch.  Perhaps tempname.c
should use uint_fast36_t or uint_fast64_t instead of uint64_t, but
this patch simply defines uint64_t and leaves the rest of the code
alone.

I'll CC: this to bug-glibc.

2001-03-16  Paul Eggert  <address@hidden>

        * sysdeps/posix/tempname.c (uint64_t): Define to uintmax_t if
        not defined, and if UINT64_MAX is not defined.

===================================================================
RCS file: RCS/tempname.c,v
retrieving revision 2.2.0.3
retrieving revision 2.2.0.4
diff -pu -r2.2.0.3 -r2.2.0.4
--- tempname.c  2001/02/27 01:58:45     2.2.0.3
+++ tempname.c  2001/03/16 11:25:34     2.2.0.4
@@ -107,6 +107,15 @@
 # define __secure_getenv getenv
 #endif
 
+/* Use the widest available unsigned type if uint64_t is not
+   available.  The algorithm below extracts a number less than 62**6
+   (approximately 2**35.725) from uint64_t, so ancient hosts where
+   uintmax_t is only 32 bits lose about 3.725 bits of randomness,
+   which is better than not having mkstemp at all.  */
+#if !defined UINT64_MAX && !defined uint64_t
+# define uint64_t uintmax_t
+#endif
+
 /* Return nonzero if DIR is an existent directory.  */
 static int
 direxists (const char *dir)