Thread: Re: your mail
Hi! 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? > BTW i appreciate the work on postgres it is an awesome package Welcome! Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they justGOSUB without RETURN.
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.
On Thu, 11 Feb 1999, D'Arcy J.M. Cain wrote: > > 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. That is what I think of, and what I usually use - tweak compiler options to unsigned char. So, my conclusion - reject the patch and teach people to change compiler options. Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they justGOSUB without RETURN.
Ah, here is the e-mail objecting to the unsigned patch. > Hi! > > 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? > > > BTW i appreciate the work on postgres it is an awesome package > > Welcome! > > Oleg. > ---- > Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net > Programmers don't die, they just GOSUB without RETURN. > > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Ah, here is an even clearer statement on unsigned. > On Thu, 11 Feb 1999, D'Arcy J.M. Cain wrote: > > > 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. > > That is what I think of, and what I usually use - tweak compiler options > to unsigned char. > So, my conclusion - reject the patch and teach people to change compiler > options. > > Oleg. > ---- > Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net > Programmers don't die, they just GOSUB without RETURN. > > > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026