[Top][All Lists]
[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
Re: [gnugo-devel] hash.h: cygwin has no <stdint.h>, Jens Yllman, 2003/08/06