Re: [Nmh-workers] Compiler warnings and signed vs. unsigned char, again

[Ken Hornstein]

>How about this:  use unsigned char everywhere we can
>internally and compile with gcc -funsigned-char/Solaris cc
>-xchar=u?  Preserving that suggests using our own unsigned
>char type, though.

Yeah, that feels wrong to me ... I mean, part of the motivation here is
to get away from specific C compiler options.

>Or maybe better:  we could funnel all C lib calls through
>macros that have the casts.  It's not as bad as it sounds,
>just throw some perl at it.  I've done it in the past and
>not regretted it.  We already have a mishmash with
>mh_str{,n}casecmp and mh_x*alloc (though those has added
>value).

Hrm .... I dunno, I'd have to think about that.

>> That seems to be what other packages have done.  This
>> would mean we'd change back all current unsigned char *'s
>> to just char *'s
>
>That just doesn't seem right.

Well, that's how it was for a while.  And if you look at the actual
_interfaces_ defined in the C standards, char * is the right type for
a NUL-terminated C string.  From what I can tell, the only reason the
ctype macros take "int" is because they can handle an EOF, and it seems
wrong to have to go through all of these gyrations when the ctype
macros/functions are the ones causing the problem.  Converting over
wholesale to unsigned char seems like we're really swimming upstream.

--Ken