> I don't believe that would solve anything really, because we are
> still trying to collapse two different types (regardless of its
> machine representation) in one. The same would happen with 'int'
> (for which we do have differentiated its signess).
>
> Well, what we need is to operate on unsigned chars (values 0 -
> 255). The problem is to have to cast the (char *) arguments in systems
> where char is signed by default.
Hah, jemarch I'm confused now. You say we should use the
-funsigned-char flag and declare pdf_char_t as 'char' ? Help me
here.
I will try to clarify the issue; also for me, since I am starting to
get confused too :)
pdf_char_t was introduced after the idea of having an abstract data
type containing _unsigned_ character codes from 0 to 255. Some code
relies on that.
We get the desired semantics for pdf_char_t with:
/* PDF manages bytes with values in the range 0-255 */
typedef unsigned char pdf_char_t;
Now, the 'char' data type is signed in some architectures (such as
intel) and unsigned in others (such as ppc). So it is getting
embarrassing to have to cast pdf_char_t pointers when calling system
functions expecting pointers to char, like in:
strncpy((char *)&(text_context.host_encoding.name[0]), charset,
length);
Using -funsigned-char the compiler would turn the char data type to an
unsigned one even if running in a signed-char architecture. In that
way we would not need to include all those casts. That was my point
regarding -funsigned-char.
