445,654 Members | 936 Online
Need help? Post your question and get tips & solutions from a community of 445,654 IT Pros & Developers. It's quick & easy.

 P: n/a 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. Dec 10 '05 #1
9 Replies

 P: n/a an**************@googlemail.com 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 Dec 10 '05 #2

 P: n/a an**************@googlemail.com 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 #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. Dec 10 '05 #3

 P: n/a Tydr Schnubbis wrote: an**************@googlemail.com 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 #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. Dec 10 '05 #4

 P: n/a On 10 Dec 2005 12:15:34 -0800, "an**************@googlemail.com" wrote: I know that char will always be one byte, and that the size of a bytemight not be 8-bits on some computers.Does that mean that an unsigned char might be able to hold numberslarger than 255 on some computers?I need to know as the program I've written relies on unsigned char toact as an 8-bit byte, and I need any unsigned char holding 255 tooverflow to 0 when the ++ operator is applied. In addition to what the others have said, there is a constant CHAR_BIT defined in which you can use to determine how many bits one char will hold. -- Bob Hairgrove No**********@Home.com Dec 10 '05 #5

 P: n/a 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 ..? Dec 11 '05 #6

 P: n/a On 10 Dec 2005 12:33:40 -0800, "peter steiner" wrote in comp.lang.c++: an**************@googlemail.com 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.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Dec 11 '05 #7

 P: n/a Jack Klein wrote: On 10 Dec 2005 12:33:40 -0800, "peter steiner" wrote in comp.lang.c++: an**************@googlemail.com 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 Dec 11 '05 #8

 P: n/a fo*******@hotmail.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 Dec 11 '05 #9

 P: n/a peter steiner wrote: fo*******@hotmail.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 Dec 11 '05 #10

### This discussion thread is closed

Replies have been disabled for this discussion.