Re: [pdf-devel] Problems with task #64

[jemarch]

    >    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.