Eric Blake <[EMAIL PROTECTED]> writes: > How about the following alternative - at configure time, if there is a > mismatch between sizeof(uintmax_t) and sizeof(intmax_t), we redefine these > two types to be the same size as the smaller of the two (effectively > disabling long long on Tandem NSK since there is no counterpart unsigned > long long).
We can do that if it's a common problem. Currently, though, I think the proposed solution is 'just compile with -O on old NSK'. If you compile with -O, long long int has a bug that 'configure' will detect (assuming latest CVS), and it won't define HAVE_LONG_LONG_INT. That should be good enough to get things to work on that platform, albeit only with 32-bit types. At least that's the theory -- I don't think anyone has tried it. > Matt, can you refresh my memory - does NSK actually provide uintmax_t and > intmax_t? Or does it just provide long long, where the gnulib configure > hooks were detecting that it could be used for the definition of a uintmax_t? As I recall, it provides only long long. We're talking about "old" NSK here. Starting last year HP began supporting 64-bit unsigned long long int for NSK. This is partly why I am not that enthusiastic about going to a lot of work to support this port -- it's dying away as we speak, albeit verrryy verrryy slowly as NSK is such a stable system.
