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

[Paul Eggert]

> Date: Wed, 6 Nov 2002 14:59:18 +0100 (CET)
> From: Bruno Haible <address@hidden>
> 
> For size_t you don't need anything more than 'unsigned long'.

True.  But suppose I want to do a gcd of two off_t values?  off_t is
wider than unsigned long on many platforms.  And there are other types
like that, e.g. blkcnt_t.

> 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.  However, the GNU Coding Standards already
say that we don't have to worry about this issue on that platform, so
I'm mentioning this only if someone else brings it up.


One typically needs to do gcd inline to get the most efficiency, but
if a 32-bit G.C.D. function is important for your application, how
about if we put a macro into gcd.h that will declare a static inline
G.C.D. function for any integer type, and then instantiate that macro
for the various integer types that we think would be useful?  We could
start with unsigned long and with uintmax_t, and call those two
functions "gcdul" and "gcdumax".  Making the functions inline should
improve their efficiency too.

It's too bad we can't use the C99 <tgmath.h> mechanisms in portable
code; that would make this more readable, as we could then use plain
"gcd".  Perhaps once GCC supports tgmath, we can use its facilities to
implement plain "gcd" appropriately, and define "gcd" to be "gcdumax"
on other compilers.