News for hackers. Stuff that matters.
Re:The Little C Function From Hell by cperciva on Wednesday June 20, 2012 @04:04AM (#4136032)
Every problem has a solution which is simple, elegant, and doesn't work. This is it.

Section 6.10.1, paragraph 4: "... For the purposes of this token conversion and evaluation, all signed integer types and all unsigned integer types act as if they have the same represenation as, respectively, the types intmax_t and uintmax_t..."

Inside preprocessor directives, your chars aren't chars any more.

Re:The Little C Function From Hell by krollew on Thursday June 21, 2012 @06:32AM (#4141277)
So what they are? Why it doesn't work? Your quote don't clarify.
Re:The Little C Function From Hell by cperciva on Thursday June 21, 2012 @10:15AM (#4142050)
Your "char" in a preprocessor directive is either a uintmax_t or an intmax_t. Either way, it's going to end up as #if 128 > 127 or #if 256 > 255 -- so the first case will always end up being included.
Re:The Little C Function From Hell by krollew on Friday June 22, 2012 @02:29AM (#4145719)
It's standard behaviour or one compiler does so? Outside preprocessor char has another meaning? Thanks anyway.
Re:The Little C Function From Hell by cperciva on Friday June 22, 2012 @03:27AM (#4145832)
Outside of the preprocessor, the char type is a one-byte integer (whether it's signed or not is implementation-defined).
Re:The Little C Function From Hell by krollew on Friday June 22, 2012 @04:44AM (#4145995)
So the good solution is make a test that finds it out, for example in configuration script and set proper preprocessor constant and test that constant instead.