bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: glibc sysdeps/posix/tempname.c: uint64_t problem on non-glibc hosts
Date: Fri, 16 Mar 2001 15:19:17 -0800 (PST)

Ulrich Drepper <address@hidden> wrote:
> uintmax_t is a C99 type and if it is available uint64_t is as well.

Actually, C99 requires uintmax_t but it does not require uint64_t.
Conversely, some pre-C99 environments have uintmax_t but not uint64_t,
e.g. 32-bit Solaris 8 with _NO_LONGLONG.

The simplest fix for self-contained portability would be to replace
uint64_t with uintmax_t in tempname.c.  The code would still work in
glibc, and it would also work with fileutils etc.

The downside of this simple fix is that uintmax_t is typically slower
on hosts where uintmax_t is wider than uint64_t.  There aren't many
hosts like that now, but I suppose there may be more in the future.
If you want to avoid that potential performance downside,
uint_fast64_t would be a better choice for tempname.c than uint64_t,
as uint_fast64_t is more portable and it might be faster.  However,
simply using uint_fast64_t would mean the code won't work on many
older pre-C99 hosts (please see below).


> From: Jim Meyering <address@hidden>
> Date: 16 Mar 2001 23:09:48 +0100

> It's better for the packages I maintain (fileutils, textutils, sh-utils)

and for the packages I help maintain (tar, diffutils, ...)....

> because I already have a test that defines uintmax_t on systems that
> lack the definition, but I have no test that defines uint64_t if it
> is not defined.

We can't define a general autoconf test for uint64_t, for two reasons.
First, strictly speaking, there may not be such a type, even if we
assume C99 -- we might be on a 36-bit int host with 72-bit uintmax_t,
for example.  Second, and more important, many older (pre-C99) hosts
don't have 64-bit ints.


Ulrich Drepper <address@hidden> wrote:
> Of course you can define uintmax_t in config.h or similar headers
> but this is not how we do this normally.

That is how fileutils, tar, etc. do it: they define uintmax_t in
config.h for hosts that do not have uintmax_t.  This follows the
tradition of size_t, etc.: it allows us to use glibc routines without
having to modify them.  But the same strategy can't work for uint64_t
in general because that type might not exist at all.


> The file should be self-contained.

The submitted patch attempted to isolate this issue into one 3-line
bit of code, in order to avoid the potential performance downside
mentioned above.  You can instead globally substitute uintmax_t for
uint64_t in tempname.c; this will make the code self-contained, albeit
a bit slower on hosts with 128-bit uintmax_t.  Another possible
approach is to apply the submitted patch and then uniformly replace
uint64_t with uint_fast64_t.

If you like, I can submit a patch along any of these lines.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]