gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] hash.h: cygwin has no <stdint.h>


From: Arend Bayer
Subject: Re: [gnugo-devel] hash.h: cygwin has no <stdint.h>
Date: Wed, 6 Aug 2003 13:08:05 +0200 (CEST)

On 6 Aug 2003, Dave Denholm wrote:

> Arend Bayer <address@hidden> writes:
>
> > Hi,
> >
> > > The subject says it, fixed by this patch.
> >
> > > I am not sure how many OSses lack an <stdint.h> and
> > > whether we need a configure test for this.
> >
>
> > Exactly. We will just not use it, and use "int" instead of "uint32_t",
> > as the latter is not always available.
> >
>
> but the former is of some random size..?
>
>
> Wouldn't it be better to create a gg_int.h which ensures that uint32_t
> etc is provided, either by including <stdint.h> if there is one,
> or creating some itself ?
>
> Or safer, perhaps, to have gg_uint32_t  which is typedefed to uint32_t
> if there is one, or to unsigned int (with checks that int is indeed 32 bits)
>
> Unfortunately, I'm not sure standard c lets you ask if a typename is known,
> which makes it a little hard to test.  (eg there may not be a header called
> stdint.h, yet including stdio.h might make these types appear anyway.

I am not sure it is worth any hassle. If int is 64bit, this will just
increase the size of the hash nodes from 96 bits to 128 bits. I.e.
25% loss, but alignment gain. Now how often does gnugo run on a systerm
with 64bit ints?

But I have nothing against a patch to add an autoconf machinery to create
a gg_uint32_t.

Arend







reply via email to

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