[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] char args passed to isalpha() et al.
From: |
Joel Reicher |
Subject: |
Re: [Nmh-workers] char args passed to isalpha() et al. |
Date: |
Wed, 11 Apr 2007 21:54:27 +1000 |
> >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