gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] platform dependency fix


From: Jens Yllman
Subject: Re: [gnugo-devel] platform dependency fix
Date: Fri, 10 Sep 2004 10:51:13 +0200 (CEST)
User-agent: SquirrelMail/1.4.3a

Hi,

> In C the type "char" may be either signed or unsigned, at the compiler
> implementor's discretion. With gcc char is by default signed but it's
> possible to change it to use unsigned with the flag -funsigned-char.
> This turns up a difference in reading node consumption, which
> shouldn't be there.
>
> The problem turned out to be in the code to mark relevant eyespaces in
> owl_determine_life(). Changing some (occasionally overflowing) char
> arrays into int arrays solves it.

I don't know why this was a char array. But if it is to save memory it
might be better to always force it to unsigned or signed char.

My suggestion to remedy this kind of problem is to make GNU Go specific
typedefs that is controlled by what compiler/platform is used. Or use the
int#_t or uint#_t typedefs in stdint.h. I do not know the C/C++ standard
include files that well to know if this realy is standard and can be
garantied to exist in most compiler enviroments.

> After this patch the node counts for the full regressions are
> identical with signed and unsigned chars. There is one failed test
> case, trevor:410, but I don't know whether that's already in CVS (3.6
> branch).
>
> - use int arrays instead of char arrays to mark eyes in
>   owl_determine_life() and dependent functions
>
> /Gunnar

Unother small note. C/C++ programmers in general tend to use int for every
thing by default. But often the value to put in the variable is unsigned.
And also quite often you have to know the bit length to be sure things
work. So I think the GNU Go project should think about how to use base
types like char/int in the future.

The plus to use [unsigned] int is that you know that this is the 'optimal'
size for speed on the current processor. Which often is not the most
important aspect of a number.

Jens Yllman





reply via email to

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