Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
I have a problem building on Tandem/NSK OSS; specifically, uintmax_t
(unsigned long long) is not a valid data type (don't ask me why!).
Sorry, but we've gotta ask why. Why isn't it a valid data type?
Does the compiler reject 'unsigned long long int x;'? Or does
it mishandle code generated with that type? Or what?
If you read the bottom of my original post, I already answered that:
"Unsigned long long: The C++ standard does not specify the long long
integer data type; however, it does state that signed integer data types
should have an unsigned counterpart. None of the compilers on the TNS/R
platform define an unsigned 64-bit data type, and C++ is no exception."
"*None of the compilers... define an unsigned 64-bit data type...*" If
you want to know /why/ they don't, you'll have to ask HP.
I am thinking about changing this to 'long long',
That would break a lot of code. I wouldn't do it.
Would it be better to change it to 'unsigned long' instead?
uintmax_t should be the widest unsigned integer type that works.
If that's 'unsigned long int', then you should use 'unsigned long int'.
C does not require that uintmax_t and intmax_t must have the same
width. However, I suspect that some gnulib code does assume that
uintmax_t is wide enough to represent any nonnegative integer value,
which means you may run into trouble if intmax_t, off_t, etc. are
wider than uintmax_t.
So what would be your recommendation? Remove all use of 64-bit integers?
(i.e. make intmax_t also 'long' rather than 'long long'?) And I wonder
why I don't remember running into this with 5.97?
Also, I don't remember this problem with 5.97 (but I could be wrong);
I think there may be some problems with files that double-include
<config.h>. That is a no-no nowadays, since <stdint.h> redefines
uintmax_t and the like. I'll try to look into it.
Thanks. (Hmm, that sounds like you got off on a tangent talking about my
Tru64 problem?)
--
Matthew
"What's Cygwin?" you ask.
'Tis mostly absurd software
Concerning hippos.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
