Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #18298

Re: Compiler warning about comparison always false

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.lang.c
Subject Re: Compiler warning about comparison always false
Date 2012-03-07 14:06 -0500
Organization A noiseless patient Spider
Message-ID <4F57B1A4.509@verizon.net> (permalink)
References <c0930b34-a2df-4588-9fb2-1ae3d33785e4@or10g2000pbc.googlegroups.com> <11715727.4312.1331141528977.JavaMail.geo-discussion-forums@vbze11> <0ff5f6eb-9f17-42a0-a031-88df3399228c@y10g2000vbn.googlegroups.com>

Show all headers | View raw


On 03/07/2012 12:42 PM, Nachy wrote:
> On Mar 7, 12:32 pm, bert <bert.hutchi...@btinternet.com> wrote:
>> On Wednesday, March 7, 2012 5:25:57 PM UTC, Nachy wrote:
>>> I got an interesting warning message from my compiler, and before I
>>> complain about a bug I want to make sure what's going on.
>>
>>> I have a method  disp_char, meant to append a character to a string,
>>> or a period if the character is a control character. The string better
>>> be the right size (it is, that's not the issue).
>>
>>> int disp_char(int c, char *s)
>>> {
>>>    char ch = c & 0xFF;                                         // make sure it's a char
>>>    if (ch < 0x20 || ch == 0x7F || ch == 0xFF)           // special character?
>>>            *s = '.';
>>>    else
>>>            *s = ch;
>>>    *++s = '\0';
>>
>>>    return 1;
>>> }
>>
>>> On one system I compiled with, gcc gave me a warning:
>>> $ gcc -o ../dump dump.c
>>> dump.c: In function `disp_char':
>>> dump.c:140: warning: comparison is always false due to limited range
>>> of data type
>>
>>> I separated the comparisons, and gcc seems to be complaining about the
>>> last one (ch == 0xFF).
>>
>>> Am I doing something wrong, or is gcc being paranoid?
>>
>>> BTW, on another system, gcc did not complain at all, even with -Wall.
>>> The program seems to work fine, although I can't seem to generate a
>>> test case with an actual file.
>>
>> You'd expect a warning on a system where the range
>> of type 'char' was from -128 to +127, and not a
>> warning on a system where it's from 0 to +255.
>> Maybe you should be doing the comparisons with
>> the int result of (c & 0xFF), instead of the
>> char result, because the constants that you're
>> comparing with aren't of type 'char'.
>> --
> 
> Thanks.  I've been working with another language recently (figure out
> which one), one without explicitly 'signed' and 'unsigned' data types,
> where char is always unsigned (and 2 bytes...), so I forgot that
> detail.  I'll change it to unsigned char to fix.
> 
> I'm using an int because that's what fgetc() returns, and I'm using a
> char because I don't think *s = ch will work if ch is an int - I'd
> rather not deal with implicit casts.

"If the end-of-file indicator for the input stream pointed to by stream
is not set and a next character is present, the fgetc function obtains
that character as an unsigned char converted to an int ..." (7.21.7.1p2).

If CHAR_MAX < 0xFF, which is implied by the warning message you're
complaining about, then if c is a value returned by fgetc(), the
expression (c & 0xFF) can still have a value > CHAR_MAX, in which case
the statement

	char ch = c & 0xFF;

attempts to convert to char a value that cannot be represented in a
char. For a signed type, this will either produce an
implementation-defined result, or raise an implementation-defined
signal. The signal is rather unlikely, and the implementation-defined
result stands a very good chance of being exactly what you want -
compiler vendors aren't generally suicidal, and on most systems the
behavior you want is precisely the most natural way of implementing such
conversions. However, it would be better if the validity of your code
wasn't left to chance. You should declare them as "unsigned char ch" and
"unsigned char *s"; then the only problem you need to deal with is EOF.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Compiler warning about comparison always false Nachy <mazwolfe@gmail.com> - 2012-03-07 09:25 -0800
  Re: Compiler warning about comparison always false bert <bert.hutchings@btinternet.com> - 2012-03-07 09:32 -0800
    Re: Compiler warning about comparison always false Nachy <mazwolfe@gmail.com> - 2012-03-07 09:42 -0800
      Re: Compiler warning about comparison always false Philip Lantz <prl@canterey.us> - 2012-03-07 10:17 -0800
        Re: Compiler warning about comparison always false Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 15:30 -0700
          Re: Compiler warning about comparison always false Philip Lantz <prl@canterey.us> - 2012-03-14 00:55 -0700
      Re: Compiler warning about comparison always false James Kuyper <jameskuyper@verizon.net> - 2012-03-07 14:06 -0500
        Re: Compiler warning about comparison always false Fred <fred.l.kleinschmidt@gmail.com> - 2012-03-07 11:11 -0800
  Re: Compiler warning about comparison always false "io_x" <a@b.c.invalid> - 2012-03-07 18:51 +0100
  Re: Compiler warning about comparison always false falk@rahul.net (Edward A. Falk) - 2012-03-07 20:29 +0000
    Re: Compiler warning about comparison always false Keith Thompson <kst-u@mib.org> - 2012-03-07 14:36 -0800
  Re: Compiler warning about comparison always false Markus Wichmann <nullplan@gmx.net> - 2012-03-07 21:26 +0100
  Re: Compiler warning about comparison always false Kaz Kylheku <kaz@kylheku.com> - 2012-03-14 17:49 +0000

csiph-web