int8_t becomes unsigned when /J is specified

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile program requiring int8_t using /J
2. ???
3. Profit!

What is the expected output? What do you see instead?
The expected output would be int8_t remaining signed while the specific
"char" type would become unsigned.  This is the behavior of gcc with the
-funsigned-char parameter, which is equivalent to /J.

It looks like the C99 standard specifies that int8_t should always be
signed, so this bug applies to this specific project's header and not
MSVC's __int8 as MSVC is of course not C99 compliant.

The fix is of course the simple matter of altering the 2 lines of stdint.h
in question. :)

Original issue reported on code.google.com by term...@gmail.com on 6 Jun 2009 at 12:43

[GoogleCodeExporter]

__int8 is internally typedefed to 'char', which is a separate type from 'signed 
char'.

Because the sign of 'char' is implementation defined by the C99 standard, 
it is necessary to replace the line:

typedef __int8            int8_t;

to be:

typedef signed __int8            int8_t;

in order to be standards compliant.

This bug is significant because 'signed char' and 'char' must be specialized for
separately even if 'char' is signed, and that results in bugs if this line is 
not
fixed as shown above.

Original comment by hlaw1...@gmail.com on 16 Sep 2009 at 10:02

[GoogleCodeExporter]

Yep, exactly.  Finding this bug was a huge pain in the ass; I use this header 
in my
Duke Nukem 3D port (it's called EDuke32) and it lead to all kinds of strange 
crap
occurring with completely nonsensical debugger output.

Hope this project isn't dead/hope this important bug doesn't go ignored!  
Actually, I
hope Microsoft pulls their collective heads out of their asses and just 
implements
most of C99, but fat chance that's ever going to happen.

Original comment by term...@gmail.com on 17 Sep 2009 at 7:00

[GoogleCodeExporter]

Sorry guys, this project is not dead, I just have not so much free time.
You know, the best way to fix a bug is to attach a patch to bug report ;)

Anyway, this should be fixed now in r25. Please check it out.

Original comment by alexander.chemeris on 17 Sep 2009 at 7:52

• Changed state: Fixed