By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,658 Members | 1,908 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,658 IT Pros & Developers. It's quick & easy.

unsigned char

P: n/a
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 ???.
Nov 14 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
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
Nov 14 '05 #2

P: n/a
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|unsigned} 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*******@freenet.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
Nov 14 '05 #3

P: n/a
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.

Nov 14 '05 #4

P: n/a
Thomas Stegen <ts*****@cis.strath.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)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #5

P: n/a
Christopher Benson-Manica wrote:
Thomas Stegen <ts*****@cis.strath.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.
Nov 14 '05 #6

P: n/a
Jeremy Yallop <je****@jdyallop.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)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #7

P: n/a
Christopher Benson-Manica wrote:
Jeremy Yallop <je****@jdyallop.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.
Nov 14 '05 #8

P: n/a
Jeremy Yallop <je****@jdyallop.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)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #9

P: n/a
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
Nov 14 '05 #10

P: n/a
"Thomas Stegen" <ts*****@cis.strath.ac.uk> wrote:
Hallvard B Furuseth wrote:
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.


Well, no, it would still be a constraint violation because of the
incompatible types in the initialisation. The type (char *) is
never compatible with the type (unsigned char *), and nor is it
ever compatible with the type (signed char *).

To make it legal you can either use a cast, or an intermediate
variable of type (void *) as conversions to and from (void *)
do not require casts.

Example with cast:
char *foo = 0; /* Properly initialise */
unsigned char *bar = (unsigned char *)foo; /* Convert with cast */

Example without cast:
char *foo = 0; /* Properly initialise */
void *bar = foo; /* Convert to (void *) */
unsigned char *baz = bar; /* Convert from (void *) */
But even
int *p;
int *p2 = p;

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


Though this is not a contraint violation, it is merely undefined
behaviour, so the compiler is not required to detect it and
generate a diagnostic message.

--
Simon.
Nov 14 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.