freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Devel] Bug in ftconfig.h for HP-UX


From: G.W. Lucas
Subject: [Devel] Bug in ftconfig.h for HP-UX
Date: Mon, 26 Mar 2001 15:52:49 -0500

Dear Sirs,

I recently encountered a bug in the ftconfig.h which rendered
me unable to compile application code on the HP-Unix platform.
A description and suggested fix follows.

Before I go any further, though, I would like to express my
gratitude for a truly neat bit of coding.   Thank you very
much for providing such an excellent tool.

                                          gary


The Bug

At our installation we are required to use the native system compilers
wherever it is feasible to do so.   This is not an unreasonable requirement
since a good bit of our work is with legacy code.  Anyway, while I used the
GNU products (gmake and gcc) to build the libraries, I needed to use the 
system's standard tools for compiling any applications that I
wrote using the freetype API.   

Things went smoothly under Sun Solaris, but when I moved over to the
HP platform, I received the following error message when compiling
one of my modules (which included
freetype-2.0.1/include/freetype/config/ftconfig.h)

   Unsupported number of bytes in 'int' type! 

After a moment of intense panic and despair, I check the code to
find the following block of code

    67    /* The number of bytes in an `int' type.  */
    68  #if   UINT_MAX == 0xFFFFFFFF
    69  #define FT_SIZEOF_INT  4
    70  #elif UINT_MAX == 0xFFFF
    71  #define FT_SIZEOF_INT  2
    72  #elif UINT_MAX > 0xFFFFFFFF && UINT_MAX == 0xFFFFFFFFFFFFFFFF
    73  #define FT_SIZEOF_INT  8
    74  #else
    75  #error "Unsupported number of bytes in `int' type!"
    76  #endif

It turns out that the HP ANSI-C compiler (it's called "c89") sees 
0xFFFFFFFF as SIGNED INTEGER...   with "all bits set" meaning -1.
If you look at the <limits.h> header file under HP-UX and SunOS, you see 

   #define   UINT_MAX 4294967295U /* max value of an "unsigned int" */

Sun and HP electing to use the decimal equivalent to the hex string.

But, no matter, it was easily fixed.   By tacking on a U to the end
of the Hex string, it was coerced to an unsigned quantity.  After changing
the code to read

   #if UINT_MAX == 0xFFFFFFFFU  

everything worked fine.

To me, it seems natural to assume that if a programmer specifies a
number in HEX, he probably wants it to be an unsigned quantity.
On the basis of this recent experience, I gather that the authors
of gcc and Sun's C compiler felt the same way.   However, it might
be advisable to add the U to hex strings in future releases in order
to ensure that they are treated that way.   I should add, however,
that I have not yet tested this change under any platform except 
Sun and HP.
 

                                   gary




reply via email to

[Prev in Thread] Current Thread [Next in Thread]