[Top][All Lists]
[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
- [Devel] Bug in ftconfig.h for HP-UX,
G.W. Lucas <=