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

[Joel Reicher]

> >isalpha() will cope with a -ve int if EOF is such a number. That's
> >why it takes an int to begin with.
> 
> The C standard says:
> # In all cases the argument is an int, the value of which shall
> # be representable as an unsigned char or shall equal the value of
> # the macro EOF. If the argument has any other value, the behaviour
> # is undefined.

Yes, I read that too. I guess I wasn't clear with what I said; I only
meant the EOF might be a -ve int, so isalpha() won't "blow up" on
just any -ve number.

I see now, however, that it probably means a sign extension on the
char being passed will never be the right thing to do.

> >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.
> 
> I'm not totally sure it's worth the effort. I do think that we should
> either do that, or do the cast to (unsigned char) where we're using
> it in these isalpha() etc functions. Anything else is leaving the code
> buggy.

I'll make the change to unsigned char. As far as I can see now it won't
introduce new bugs, it just might eliminate some of the old ones.

I won't do explicit casts though. It's simpler to change the function
and variable declarations in which isalpha() et al. are called, and then
the char* -> unsigned char* implicit cast when those functions are called
will take care of the rest.

Cheers,

        - Joel