[Top][All Lists]
[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.