Re: Removing forced casts between signed/unsigned char pointers

[Wayne Davison <wayned@users.sourceforge.net>]

On Tue, Nov 15, 2005 at 11:00:09AM +0100, DervishD wrote:
> If you go for portability, you shouldn't assume that a plain char is
> equivalent to "unsigned char".

I'm not -- I'm assuming that "char" is probably signed while making sure
that the code works irrespective of it being signed or not.  What I want
to avoid is a bunch of switching back and forth between the two pointer
types.  I like to avoid pointer casts where possible because they can
hide bugs.  For instance, it's easy to think that we're casting one
pointer type to another when we're really forcibly casting a character
value or an int into a pointer -- the casts are coded the same way, and
C will not complain about it if it's an explicit cast.  (Yes, we could
use inline functions under a compiler like gcc and code up type-safe
conversions, but I think it's better to pick a single char type and
stick with it than to do a bunch of converting back and forth.)

> If you don't mind me suggesting, you should use "unsigned char"
> wherever possible, and cast to plain "char" when needed.

I certainly wouldn't mind if all of zsh were switched over to using
unsigned chars for its strings, but that's a MUCH larger change than
what I did (my changes mainly affected the ZLE code).  Switching all of
zsh to unsigned chars would also involve some kind of a wrapper scheme
for standard C functions that we use (e.g. strcpy(), strcmp(), strchr(),
etc.), which might be a little annoying, but probably wouldn't be too
bad.

The main thing zsh needs is consistency of type and good coding
practices to avoid any problems with signed characters.  Yes, such
coding practices are slightly easier to get right when using unsigned
chars, but zsh already has several idioms in place that are geared
towards making sure that signed characters are handled correctly.

That's my opinion, at least.

..wayne..