bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils-6.4 released (stable)


From: Paul Eggert
Subject: Re: coreutils-6.4 released (stable)
Date: Fri, 17 Nov 2006 09:55:45 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Eric Blake <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]