unsigned char

[Lars Tackmann]

Does the c standard state that for all c99 implementation char as standard
is equal unsigned char ??? - or do i have to take this into account when
writing my program ???.

[Hallvard B Furuseth]

Lars Tackmann wrote:

Does the c standard state that for all c99 implementation char as standard
is equal unsigned char ?

Not at all. It's equivalent to either signed char or unsigned char.
The choice is up to the implementation.

It's not _equal_ to either, though. It's a distinct type, so
char *foo;
unsigned char *bar = foo;
is an error even if char is equivalent to unsigned char.

--
Hallvard

[Irrwahn Grausewitz]

Lars Tackmann <ro****@diku.dk > wrote:

Does the c standard state that for all c99 implementation char as standard
is equal unsigned char ??? - or do i have to take this into account when
writing my program ???.

The implementation has to pick one from {signed|unsigne d} char
for "plain" char:

ISO/IEC 9899:1999 6.2.5#15
The three types char, signed char, and unsigned char are
collectively called the character types. The implementation
shall define char to have the same range, representation,
and behavior as either signed char or unsigned char.

and

ISO/IEC 9899:1999 6.3.1.1#3
The integer promotions preserve value including sign. As
discussed earlier, whether a "plain" char is treated as
signed is implementation-defined.
HTH
Regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html

[Thomas Stegen]

Hallvard B Furuseth wrote:

Lars Tackmann wrote:

Does the c standard state that for all c99 implementation char as standard
is equal unsigned char ?

Not at all. It's equivalent to either signed char or unsigned char.
The choice is up to the implementation.

It's not _equal_ to either, though. It's a distinct type, so
char *foo;
unsigned char *bar = foo;
is an error even if char is equivalent to unsigned char.

Note that pointers to unsigned char can point to any byte in an object.
So if foo had been properly initialised the above would have been legal.

But even
int *p;
int *p2 = p;

is an error since it uses the value of an uninitialised variable.

--
Thomas.

[Christopher Benson-Manica]

Thomas Stegen <ts*****@cis.st rath.ac.uk> spoke thus:

int *p;
int *p2 = p;

Is ( p==NULL ) likewise undefined?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Jeremy Yallop]

Christopher Benson-Manica wrote:

Thomas Stegen <ts*****@cis.st rath.ac.uk> spoke thus:

int *p;
int *p2 = p;

Is ( p==NULL ) likewise undefined?

Yes. No expression that uses the value of an uninitialized pointer
variable has defined behaviour.

Jeremy.

[Christopher Benson-Manica]

Jeremy Yallop <je****@jdyallo p.freeserve.co. uk> spoke thus:

Yes. No expression that uses the value of an uninitialized pointer
variable has defined behaviour.

Does that hold true for non-pointer variables as well? Such as

int i;
if( i != 42 ) {
printf( "What a tragedy...\n" );
}

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Jeremy Yallop]

Christopher Benson-Manica wrote:

Jeremy Yallop <je****@jdyallo p.freeserve.co. uk> spoke thus:

Yes. No expression that uses the value of an uninitialized pointer
variable has defined behaviour.
Does that hold true for non-pointer variables as well?

Not in every case. Since the bit pattern of an uninitialized object
is indeterminate, whether the behaviour is defined depends on whether
all

It does, but the particular type of behaviour - undefined,
unspecified, etc. - depends on the type of the variable and possibly
on the implementation. For example, all bit patterns have valid
unsigned char values, so using an uninitialized unsigned char object
in an arithmetic expression never invokes undefined behaviour. Some
such expressions may even have well-defined behaviour; the following
assertion cannot fail.

unsigned char c;
assert(!(c - c));
Such as

int i;
if( i != 42 ) {
printf( "What a tragedy...\n" );
}

It's unspecified whether or not this code has undefined behaviour. On
an implementation where all possible bit patterns represent valid int
values the behaviour is not undefined, because the standard imposes
requirements on it: `i' has either the value 42 or some other valid
value. On an implementation with trap values for int, the code has
undefined behaviour.

Jeremy.

[Christopher Benson-Manica]

Jeremy Yallop <je****@jdyallo p.freeserve.co. uk> spoke thus:

Not in every case. Since the bit pattern of an uninitialized object
is indeterminate, whether the behaviour is defined depends on whether
all
Lose your train of thought? Did Agent Smith pay you an unwelcome
visit? ;)
It does, but the particular type of behaviour
(etc.)

Glad to see Agent Smith let you live this time. Seriously, thanks.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Hallvard B Furuseth]

Thomas Stegen wrote:

Hallvard B Furuseth wrote:

char *foo;
unsigned char *bar = foo;
is an error even if char is equivalent to unsigned char.
Note that pointers to unsigned char can point to any byte in an object.
So if foo had been properly initialised the above would have been legal.

No, assignment between different pointer types are not legal.
OTOH, using a cast is OK: unsigned char *bar = (unsigned char*) foo;
But even
int *p;
int *p2 = p;

is an error since it uses the value of an uninitialised variable.

Oops. I should have said 'char *foo = "something" ;'.

--
Hallvard