Thus spake Oleg Broytmann
> On Thu, 11 Feb 1999, Angelos Karageorgiou wrote:
> > > For me it seems like a compiler (or compiler option) problem - signed
> > > vs. unsigned chars.
> >
> > Yes you are right , the problem is BSD/OS specific , and indeed it has to
> > do with unsigned chars vs signed chars. I just did not know if others had
> > the problem too and since and a cast to (unsigned char) has no effect to
> > an 8bit char I decided to post the patch.
> >
> > Even test-ctype gives out different results when cp is cast as unsigned
> > chat and not a plain char. would you like the output from test-ctype for
> > unsigned chars ?
>
> I am not sure. This should be discussed among other developers. What we
> should use: signed or unsigned chars, anyone has an idea?
In all my own code, I always set the compiler option to make char an
unsigned type. For portability I like to know that the behaviour
won't change as long as I carry over my compiler options. I like
that way better than casting since I don't get conflict warnings
for sending unsigned (or signed) char to library functions. Remember,
char, signed char and unsigned char are 3 distinct types even though
char has to behave exactly like one of the other two. Setting it up on
the compiler command line gets around that.
As for signed vs. unsigned, I don't think it matters that much. I chose
unsigned since I never do signed arithmetic on char and if I ever did I
would like to have the extra keywork to draw attention to it.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.