On Tue, Oct 09, 2001 at 04:47:30PM -0700, Guy Harris wrote:
> 2) displaying the values on platforms that *do* support "gint64"
> and "guint64" - there's no standard for the format to use to
> print those quantities, and, while many of them support
> "%ll[doxu]", older versions of BSD don't (they support only
> "%q[doxu]"), and I don't know what the Microsoft Visual C++
> library supports, if anything.
It supports "%I64[diuoxX]", at least as I read the documentation for
Visual C++ 6.0.
I'm working on some config-script changes to search for a 64-bit-integer
format on UNIX.
However, it appears that, as of:
NetBSD 1.1
OpenBSD 1.0
FreeBSD 3.2
"%ll[diuoxX]" are supported, in addition to "%q[diouxX]", even though
they're not documented as doing so in, for example, FreeBSD 3.x; I don't
know whether there are any other UNIX platforms that don't support
"%ll[diouxX]" but support some other format.
In the commercial UNIXes, as of:
Solaris 2.5
HP-UX 10.0
"%ll[diouxX]" are supported.
GLib has a routine "g_printf_string_upper_bound()", which "calculates
the maximum space needed to store the output of the sprintf() function";
it does so by duplicating what it thinks "printf()" would do, but, at
least as of GLib 1.2.10, it thinks you use "%L[diouxX]", not
"%ll[diouxX]" or "%q[diouxX]", so perhaps there *is* a platform on which
"%L[diouxX]" is what you use - older versions of GNU libc, perhaps?
2.1.3 appears to support "%ll[diouxX]", "%q[diouxX]", and "%L[diouxX]".
If there are no currently-interesting platforms where "%ll[diouxX]"
doesn't work, we could either
1) assume that if there's a 64-bit integral data type,
"%ll[diouxX]" is supported on UNIX
or
2) check whether "%ll[diouxX]" works and, if not, act as if the
platform didn't support "gint64"/"guint64".
The former is easier, but may cause misbehavior on UNIX platforms that
have 64-bit integral data types but don't support printing them with
"%ll[diouxX]".
The latter catches that, but requires that we also check whether the
platform has "snprintf", because most of our printing will be with
"snprintf()", and, on some platforms, we have our own "snprintf()"
because the OS doesn't have it. On those platforms, we should assume
"%ll[diouxX]" works if the platform has "gint64"/"guint64", and make our
own "snprintf()" handle that.
As for converting a string to a 64-bit integral type, "strtoll()" or
"strtoq()" (BSD) are supported on many platforms - but HP-UX 10.0, for
example, doesn't, and, if the Red Hat 7.1 man pages on the FreeBSD site
are to be trusted, neither does the version of GNU libc in RH 7.1,
although there does appear to be support for it in glibc 2.1.2.
Fortunately, we could just provide our own "strtoll()" on platforms that
lack it and have "gint64"/"guint64" support.
