Re: [Nmh-workers] char args passed to isalpha() et al.

[Joel Reicher]

> I'm not sure, but I think that the problem is to do with 'signed'
> vs 'unsigned' char. isalpha() et al want a value which is an unsigned
> char. If on some platform char is signed and we do something like:
> 
>   isalpha((int)*p)  /* p is a 'char *' */
> 
> and whatever char p points to is in the -ve range then isalpha is
> entitled to blow up.

isalpha() will cope with a -ve int if EOF is such a number. That's
why it takes an int to begin with.

If the original char is -ve, that's a slightly different problem. More
below.

> So the cleanest fix is probably to make sure that we're using 'unsigned
> char *' in all the places where it matters.  The simplest fix is to use
>   isalpha((unsigned char)*p)
> (ie cast to unsigned char at point of use).
> 
> Casting to int will kill the warning but leave the problem in place, so
> it's the wrong approach.

A conversion from char to int is not the same as going via unsigned char.
The former does a sign extension, the latter does not (on my machine,
anyway).

The nmh code must, at the moment, be assuming that these chars are 7 bit
because it's doing a direct (implicit) conversion from char to int.

Since conversion via unsigned char is not bug-for-bug identical, I don't
want to drop that in and introduce new behaviour.

If I were going to change everying to unsigned char, and I agree that's
the right solution, it wouldn't be as a cast but as a change in everything
going back to the point at which the data is read in.

I'm quite prepared to do that if everyone likes the sound of it.

Cheers,

        - Joel