Re: [gnugo-devel] I stepped on a bug

[Dave Denholm]

Gunnar Farnebäck <address@hidden> writes:

> I wrote:
>> > I'd appreciate it if you'd let me know whether this signedness problem
>> > is a bug in gnugo or in gcc.
>> 
>> It's definitely a bug in GNU Go.
>
> Appended is a patch which should fix this.
>  
>> > I'm not sure whether chars are meant to be signed or unsigned by
>> > default
>> 
>> The compiler is free to choose.
>
> This was a disaster waiting to happen. I think it's time that we
> implement the following policy:
>
> Use "char" for (text) strings but nothing else. Otherwise choose
> the one of "signed char" and "unsigned char" that makes most sense in
> the context. Where signedness is unimportant, use "signed char".
>

I'd suggest either using the c99 types  int8_t, uint8_t, or inventing
new typedefs. A benefit of the latter is that you can choose to make
them aliases of the c99 types if they is available, but you can still
choose to make new names if the compiler doesn't offer the standard
names, or they are somehow broken or insufficient. (I think c++ has
the std names, but doesn't have the _max and _min values, or something
weird like that...)

It just feels wrong to use the name 'char' (even with an explicit
sign) to represent something which is a number.


My previous company had typedefs IS8, IU16, etc, containing sign and
size explicitly - I always liked that fact that it was no more effort
to choose unsigned than signed, since most of the quantities I was
working with were naturally unsigned. The default c types mean that
it's more effort to specify a more precise type, which is a bad thing
IMHO.



Another related potential portability problem is assumptions about the
size of int. There is at least one 32-bit machine who's c compiler chooses to
use 16-bit ints (for backwards compatability).


(do the gnu coding standards have anything to say on this subject ? -
ah - yes


5.6 Portability between cpus

Even GNU systems will differ because of differences among cpu
types?for example, difference in byte ordering and alignment
requirements. It is absolutely essential to handle these
differences. However, don't make any effort to cater to the
possibility that an int will be less than 32 bits. We don't support
16-bit machines in GNU. 


- doesn't seem to mention the char thing, though..?

dd
-- 
Dave Denholm              <address@hidden>       http://www.esmertec.com