[Top][All Lists]
[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