bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] addition: gcd.h, gcd.c


From: Bruno Haible
Subject: Re: [Bug-gnulib] addition: gcd.h, gcd.c
Date: Wed, 6 Nov 2002 20:24:52 +0100 (CET)

Paul Eggert writes:
> But suppose I want to do a gcd of two off_t values?

Then you create a gcdll.c file containing

   #define gcd gcdll
   #define long long long
   #include "gcd.c"

I don't want to make gcd.c less efficient for cases that don't occur
in 99% of practice.

> > No platform designer is so foolish as to use a two-machine-words
> > type for size_t.
> 
> Perhaps, but there is one major platform designer who is so foolish as
> to make the opposite mistake of having 'unsigned long' be a half-word
> type, so 'unsigned long' is narrower than size_t!  The platform is
> Microsoft Windows IA-64.

I believe that when GNU software will start being ported to that
platform, the C compiler will define 'LONG' to a 32-bit type but
'long' to the 64-bit type. Otherwise porting will be impossible,
because so many code does freely cast between 'void *' and 'unsigned long'.

> One typically needs to do gcd inline to get the most efficiency

Typically where gcd is used, there is also one or two divisions. I'm
reaching out for _reasonable_ efficiency, not for maximum efficiency.
I bet at the place where you need it in 'tar' it's not inside a tight
loop.

> We could start with unsigned long and with uintmax_t

Show me a real application case where you need gcd on uintmax_t but
don't need multiprecision integers in general.

Bruno




reply via email to

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