«

[getchar() returns a value in the range of an unsigned char, or
EOF, but we need to stuff this into plain, possibly-signed "char"s.]

In article <bdhfbj$m55$> Dan Pop <> wrote:
>One idea would be declare x as array of unsigned char. But, if you want
>to pass it to a library expecting a string, you have a problem, because
>it expects a pointer to char as argument. So, the right solution is to
>use a pointer to unsigned char when storing values into your array:
>
> int c, i = 0;
> char x[20];
> unsigned char *p = (unsigned char *)x;
>
> while((c = getchar()) != EOF && i < sizeof x - 1)
> p[i++] = c;

If one were using an implementation with signed 1s-complement
or signed-magnitude "char", this might stick trap representations
in, and would likely distort the desired values.

Such systems have other problems, though. For the most part
they might want to just make plain char unsigned, as long as
this does not lead to CHAR_MAX > INT_MAX (which raises even
more problems).

I consider this whole area a bit of a mess, and am usually willing
to restrict myself to saner systems.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

In <bdi8ab$pt6$> Chris Torek <> writes:

>[getchar() returns a value in the range of an unsigned char, or
>EOF, but we need to stuff this into plain, possibly-signed "char"s.]
>
>In article <bdhfbj$m55$> Dan Pop <> wrote:
>>One idea would be declare x as array of unsigned char. But, if you want
>>to pass it to a library expecting a string, you have a problem, because
>>it expects a pointer to char as argument. So, the right solution is to
>>use a pointer to unsigned char when storing values into your array:
>>
>> int c, i = 0;
>> char x[20];
>> unsigned char *p = (unsigned char *)x;
>>
>> while((c = getchar()) != EOF && i < sizeof x - 1)
>> p[i++] = c;
>
>If one were using an implementation with signed 1s-complement
>or signed-magnitude "char", this might stick trap representations
>in, and would likely distort the desired values.

Assigning values in the 0..UCHAR_MAX range to a char that happens to be
signed has an even higher chance of doing that, considering that the
conversion is not well defined for values above SCHAR_MAX.

>Such systems have other problems, though. For the most part
>they might want to just make plain char unsigned,

They basically have to, considering the <ctype.h> issue, too.

>as long as
>this does not lead to CHAR_MAX > INT_MAX (which raises even
>more problems).

That's downright pathological for a hosted implementation: it breaks both
<stdio.h> and <ctype.h>, whose specification implicitly assumes that the
type int can represent the range 0..UCHAR_MAX.

>I consider this whole area a bit of a mess, and am usually willing
>to restrict myself to saner systems.

Did anyone produce such a pathological hosted implementation?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: