Re: CVS commit: src/lib/libc/stdio

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Wed, Mar 28, 2012 at 11:30:50 -0400, Christos Zoulas wrote:

> On Mar 28,  5:24am, uwe%stderr.spb.ru@localhost ("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.GT26108%bigmac.stderr.spb.ru@localhost>,
> | > Valeriy E. Ushakov <uwe%stderr.spb.ru@localhost> 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:

Why this bug in our headers is relevant to this discussion?


> [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.

-uwe