Char difference between C90 and C99

[Jason Curl]

Dear C people,

C90 doesn't specify if 'char' is either 'signed char' or 'unsigned char'
leaving it to the implementation of the compiler. Has this changed for
C99, or is it still the same?

Thanks,
Jason.

[Jason Curl]

Malcolm wrote:

"Jason Curl" <j_********@mot orola.com> wrote

01 #include <stdio.h>
02 int ctest(char s)
03 {
04 if (s < 0 || s >= 128) {
05 printf("Out of range\n");
06 return 0;
07 } else {
08 printf("In range\n");
09 return 1;
10 }
11 }

file.c:4: warning: comparison is always false due to limited range of data
type

and I want to know if the compiler is generating a useless diagnostic in
this case (and I ignore it, or figure out how to turn it off), or if it is
a problem with my code.

It's a sort of useless diagnostic. What it is complaining about is that char
can never go above 128 (assuming signed 8 bit chars). It may also dislike
comparing an unsigned for less than zero (assuming unsigned chars). It
doesn't ahve the intelligence to realise that the test is potentially
meaningful on a different machine.

The way I would get rid of this is to convert s to an int. Make the function
take an integer as an argument. This is traditional in C; fgetc() and
fputc() work this way, for instance.

Not quite. I don't actually care about the text itself as humans don't
need to read it, and I'm treating it literally as a string of random
values. The range of the values concerns me as I'm using an array of
structures that's indexed by the character value itself. I'm defining that
array to be 128 elements and check that the 'char' is in the range of 0 to
127 (for a Posix system) before using it to index that char.

And of course, the actual size of a char is defined to be 8 bits (or more,
but 8 in Posix), so I interpret this as I must check the 8th bit somehow.

Using a char for indexing is possibly one of the exceptions to the rule that
the machine representation is irrelevant. Are you sure you want 128 buckets
indexed by ascii value and that the program might not be clearer, if a
little slower, if you indexed alphabetically on alphanumeric values?
Remember the program may break if you move to a non-ascii system.

Thanks for your input. You're right that it will break if it moves away
from ASCII systems (e.g. EBCDIC is spread out across 8 bits). I have to
find out though if POSIX allows for different char sets.

<OT>
The actual characters themselves are byte sequences from a terminal
(e.g. VT100). I then receive a sequence of bytes and use this method to
determine what should be done when a key is pressed. Hence for non-ascii
systems this would be a different character string - the byte sequences
remain the same but representation in the C source would have to change.
</OT>

It seems a little waste of CPU cycles/code clarity to take the value,
typecast it to int (or assign it to an int), make the comparison, then
index the array with the int as to avoid the warning.

Probably no code will be executed. The character is held in an integer wide
register, and if treated as a char variable the top bits are ignored.

[pete]

Jason Curl wrote:

Malcolm wrote:

"Jason Curl" <j_********@mot orola.com> wrote

C90 doesn't specify if 'char' is either
'signed char' or 'unsigned char'
leaving it to the implementation of the compiler.
Has this changed for C99, or is it still the same?

char may be signed or unsigned,
but this is a hangover from K and R and

That's what I originally thought. But there was another post that
suggested the defined range of char is 7 bits (0-127),

That's the minimum guaranteed range of char.
It's the intersection of the minimum guaranteed ranges
of signed char and unsigned char.
and in newer
standards is different to 'signed char' and 'unsigned char'.
There's three types of char:
1 char
2 signed char
3 unsigned char
Those are three different types.
01 #include <stdio.h>
02 int ctest(char s)

Use
int ctest(int s);
instead.

--
pete