Question about char

[anongroupaccount]

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.

[peter steiner]

an************* *@googlemail.co m wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.

the char type is defined to be large enough to hold one character of
the implementation' s basic character set (3.9.1.1). this may be
anything from 7 to 9 or even more bits in a single byte on exotic (old)
architectures.

as 8bit bytes are common on modern architectures you may probably
safely ignore the problem, but for real portability you would have to
use a bigger type and manually overflow at 255.

-- peter

[Tydr Schnubbis]

an************* *@googlemail.co m wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.

An unsigned char can be larger than 8 bits. So if you want it to be
portable, you can use the standard C99 typedef uint8_t (defined in
stdint.h). If you don't want to limit yourself to C99 compilers only,
you can use a typedef like this:

typedef unsigned char Uint8;

It might be even better if you replace 'unsigned char' with a fixed-size
type that is specific to your compiler. If you then compile on another
compiler, you will have to replace that type with a similar type
available on the new compiler, in order to make it compile. That would
lower the chance of your Uint8 getting the wrong size without anyone
noticing.

You could also use the C99 uint8_t, with a fallback for older compilers,
something like this:

#if defined(__STDC_ VERSION__) || && (__STDC_VERSION __ >= 199901L)
#include <stdint.h>
#else
typedef unsigned char uint8_t;
#endif

But in most cases, just using an int and resetting it to 0 when it
reaches 255 would be the cleanest solution. You shouldn't rely on
'tricks' like numbers wrapping around if you don't have to.

[Tydr Schnubbis]

Tydr Schnubbis wrote:

an************* *@googlemail.co m wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.

An unsigned char can be larger than 8 bits. So if you want it to be
portable, you can use the standard C99 typedef uint8_t (defined in
stdint.h). If you don't want to limit yourself to C99 compilers only,
you can use a typedef like this:

typedef unsigned char Uint8;

It might be even better if you replace 'unsigned char' with a fixed-size
type that is specific to your compiler. If you then compile on another
compiler, you will have to replace that type with a similar type
available on the new compiler, in order to make it compile. That would
lower the chance of your Uint8 getting the wrong size without anyone
noticing.

You could also use the C99 uint8_t, with a fallback for older compilers,
something like this:

#if defined(__STDC_ VERSION__) || && (__STDC_VERSION __ >= 199901L)
#include <stdint.h>
#else
typedef unsigned char uint8_t;
#endif

But in most cases, just using an int and resetting it to 0 when it
reaches 255 would be the cleanest solution. You shouldn't rely on
'tricks' like numbers wrapping around if you don't have to.

You obviously can't use C99-specific features portably in C++, so
disregard that part. The rest still applies. Sorry folks.

[Bob Hairgrove]

On 10 Dec 2005 12:15:34 -0800, "an************ **@googlemail.c om"
<an************ **@googlemail.c om> wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.

In addition to what the others have said, there is a constant CHAR_BIT
defined in <limits.h> which you can use to determine how many bits one
char will hold.

--
Bob Hairgrove
No**********@Ho me.com

[forums_mp]

I've never fully understood the issue surrounding the use of char with
regards to trap representation. I've perused the standard but I'm not
sure if I solid handle on so called trap representation. In any event,
there's seem to be an argument on both sides with some purists saying
it can and others saying it cant.
That said, is it safe to state that if a computer has an 8-bit signed
char with 255 admissible values (-127 to 127), could the potential for
'trap representation' arise here or ..?

[Jack Klein]

On 10 Dec 2005 12:33:40 -0800, "peter steiner" <pn*******@gmai l.com>
wrote in comp.lang.c++:

an************* *@googlemail.co m wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.
the char type is defined to be large enough to hold one character of
the implementation' s basic character set (3.9.1.1). this may be
anything from 7 to 9 or even more bits in a single byte on exotic (old)
architectures.

The C++ language standard requires that the char types contain at
least 8 bits. 7-bit chars are not compatible with the C or C++
standard.
as 8bit bytes are common on modern architectures you may probably
safely ignore the problem, but for real portability you would have to
use a bigger type and manually overflow at 255.

Some of the most modern architectures are digital signal processors,
and many of them have 16 or 32 bit chars in their C and C++
implementations . So apparently the only "modern architectures" you
know about are used in desk top type computers.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[peter steiner]

Jack Klein wrote:

On 10 Dec 2005 12:33:40 -0800, "peter steiner" <pn*******@gmai l.com>
wrote in comp.lang.c++:

an************* *@googlemail.co m wrote:

I know that char will always be one byte, and that the size of a byte
might not be 8-bits on some computers.

Does that mean that an unsigned char might be able to hold numbers
larger than 255 on some computers?

I need to know as the program I've written relies on unsigned char to
act as an 8-bit byte, and I need any unsigned char holding 255 to
overflow to 0 when the ++ operator is applied.
the char type is defined to be large enough to hold one character of
the implementation' s basic character set (3.9.1.1). this may be
anything from 7 to 9 or even more bits in a single byte on exotic (old)
architectures.

The C++ language standard requires that the char types contain at
least 8 bits. 7-bit chars are not compatible with the C or C++
standard.

where does it say that? i have been unable to find any more concrete
definition than the one paraphrased above.

as 8bit bytes are common on modern architectures you may probably
safely ignore the problem, but for real portability you would have to
use a bigger type and manually overflow at 255.
Some of the most modern architectures are digital signal processors,
and many of them have 16 or 32 bit chars in their C and C++
implementations .

that is the reason why i recommended to use another solution for truly
portable code. i think that developers targeting embedded platforms
know about that fact...
So apparently the only "modern architectures" you
know about are used in desk top type computers.

?

-- peter

[peter steiner]

fo*******@hotma il.com wrote:

I've never fully understood the issue surrounding the use of char with
regards to trap representation. I've perused the standard but I'm not
sure if I solid handle on so called trap representation. In any event,
there's seem to be an argument on both sides with some purists saying
it can and others saying it cant.
That said, is it safe to state that if a computer has an 8-bit signed
char with 255 admissible values (-127 to 127), could the potential for
'trap representation' arise here or ..?

the same standard clause (3.9.1.1) state that all bits in the object
representation participate in the value representation and that all
possible value bit pattern combinations represent numbers. in plain
english that means that all bits stored in the in-memory representation
of a char type are part of the number it represents, thus there is no
potential trap representation.

the way i always understood that it is exclusive to the char type that
it avoids this very problem.

-- peter

[Kai-Uwe Bux]

peter steiner wrote:

fo*******@hotma il.com wrote:

I've never fully understood the issue surrounding the use of char with
regards to trap representation. I've perused the standard but I'm not
sure if I solid handle on so called trap representation. In any event,
there's seem to be an argument on both sides with some purists saying
it can and others saying it cant.
That said, is it safe to state that if a computer has an 8-bit signed
char with 255 admissible values (-127 to 127), could the potential for
'trap representation' arise here or ..?
the same standard clause (3.9.1.1) state that all bits in the object
representation participate in the value representation and that all
possible value bit pattern combinations represent numbers.

Well, the wording in my copy of the standard is a little different:

[...] For character types, all bits of the object representation
participate in the value representation. For unsigned character types, all
possible bit patterns of the value representation represent numbers. [...]

As you can see, the guarantee that all bit patterns represent values is
restricted to unsigned char. Thus, the previous sentence just rules out
something like, e.g., a redundant parity bit in the representation or
padding. It does not rule out trap values.

in plain
english that means that all bits stored in the in-memory representation
of a char type are part of the number it represents, thus there is no
potential trap representation.
Nope, see above.

the way i always understood that it is exclusive to the char type that
it avoids this very problem.

Correct: the standard goes on to say:

These requirements do not hold for other types.
Kai-Uwe Bux