Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Removing forced casts between signed/unsigned char pointers

    Hi Wayne :)

 * Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx> dixit:
> 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.

    That's cool :) (and of course I wasn't saying that you was
assuming that, it was just a suggestion).

> 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.

    You're completely right, arbitrary casts can hide very nasty
bugs. In that sense you're right when sticking to a particular type
of char. Anyway and IMHO (since I'm not as familiar as you are with
zsh source code) going to "unsigned char" will remove a whole bunch
of casts (especially if you can change some prototypes) and it is
safer. But obviously you know LOTS more than me about zsh source
code. For example, I didn't know that zsh code can deal with signed

> > 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).

    OK, I understand. I didn't think about the extents of such

> 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.

    But zsh is already using such wrappers, isn't it? This way you
only have to change the wrapper prototypes. As I've already told, I'm
not familiar with the code to know such details. It was just a

> The main thing zsh needs is consistency of type and good coding
> practices to avoid any problems with signed characters.

    This is obvious in any project. Good coding practices can avoid
more bugs that just trying to write "proper" code (for example, using
"unsigned char" instead of plain "char"). Here you're completely
right, and as far as I know, zsh code fits your description.

> 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.

    I didn't know that, thanks for pointing :)

> That's my opinion, at least.

    And you're right. If switching to "unsigned char" can lead to
significant problems and the change is very large (in number of lines
of code affected) I don't think it is worth the effort. Anyway, if the
change can be done progressively (for example, changing the wrappers
first, after that some static variables, etc.) then it maybe worth a
try. Anyway this is just a humble suggestion since I'm not able to do
that change myself and I don't want (nor like) to say others how they
should do their work.

    Thanks for considering and discussing the idea :) And good luck
with the changes, whatever they are ;)

    Raúl Núñez de Arenas Coronado

Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Messages sorted by: Reverse Date, Date, Thread, Author