On Tue, Oct 09, 2001 at 04:47:30PM -0700, Guy Harris wrote:
> 1) making the code still compile on platforms that lack "gint64"
> and "guint64" - what we should probably do on those platforms
> is just treat the 64-bit integers as 8-byte opaque
> quantities, and display them as hex digits;
We could have "eth_int64" and "eth_uint64" types, which, on platforms
with "gint64" and "guint64", are "gint64" and "guint64", respectively,
and which, on other platforms, are structures with a member that's an
array of 8 bytes (structures so that they can be passed as arguments).
> 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.
We could, instead, have routines that take "eth_int64"s and
"eth_uint64"s as arguments, and, on platforms with "gint64" and
"guint64", format them as decimal, hex, and octal numbers, and, on other
platforms, format them as hex numbers, and return a pointer to a static
string buffer; code that wants to print them would use "%s" and the
result of those routines. The routines could do the conversion
themselves, so that they don't depend on what "snprintf()" can do.