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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers