On Mar 28, 5:24am, u...@stderr.spb.ru ("Valeriy E. Ushakov") wrote: -- Subject: Re: CVS commit: src/lib/libc/stdio
| On Tue, Mar 27, 2012 at 22:53:47 +0000, Christos Zoulas wrote: | | > In article <20120327202907.gt26...@bigmac.stderr.spb.ru>, | > Valeriy E. Ushakov <u...@stderr.spb.ru> wrote: | > > | > >But that is not what the code was. The code was: | > > | > > char c; if (c == CHAR_MAX) ... | > > | > >and *that* is portable. As I said in another mail to thsi thread that | > >went unanswered, it is literally schizophrenic of lint to complain | > >about it. | > | > How can lint know that if (c == 255) is portable? Because CHAR_MAX | > gets expanded by cpp to 255 before lint parses the file. | | And this is *precisely* why it's fundamentally wrong. It's not 80s | any more. CHAR_MAX is there for a reason. It does not really matter. It is the compilation environment that matters, and for that we don't even do it right, so lint has every right to warn: [demoed with CHAR_MIN, because of easy access to machine with signed chars, you can do the opposite test on a machine with unsigned chars] [11:26am] 10018>cat char.c #include <stdio.h> #include <limits.h> int main(int argc, char *argv[]) { char c = argv[0][0]; if (c == CHAR_MIN) printf("yes\n"); return 0; } [11:26am] 10019>cc -funsigned-char -Wall char.c char.c: In function 'main': char.c:8: warning: comparison is always false due to limited range of data type In reality I would expect a program using CHAR_MIN/CHAR_MAX to work properly with -fsigned-char or -funsigned-char in the default compilation environment. Yet, it does not. christos