int8_t/uint8_t

hello group,

is the cast of int8_t and uint8_t in char for streaming in both
directions (put(), get()) defined/plattform independent?

i have read here in the forum, that int8_t and uint8_t are guaranteed 2s
complement, ist the cast between them bit-identical (or is to big
unsigned in signed undef)?

are all three chars (char, signed char, unsigned char) on every
plattform the same size?

is there a best practise to stream char plattform independend?

thanks a lot!

cheers, chris

re: int8_t/uint8_t

On Jul 3, 2:30*am, Chris Forone <4...@gmx.atwrote:I'm not sure I understand your question; but I think the quick answer
is 'no'; at the very least you must consider endianess issues.

re: int8_t/uint8_t

"Chris Forone" <4one@gmx.atwrote in message news:g4hrm1$dsl$1@newsreader2.utanet.at...I don't think int8_t and uint8_t are defined on all platforms.
Probably.
On all platforms sizeof (char) == sizeof (signed char) == sizeof (unsigned char) == 1.
I don't understand this question, but probably there is a best practice.

re: int8_t/uint8_t

joseph cook schrieb:i only use (u)int8_t/(u)int16_t/(u)int32_t in my app. the endianess is
no problem, because i can only stream char, which is signed/unsigned
char (depends on impl.). the 16 bit i stream with Put(val >8) and
Put(val), the 32 bit with Put(val >24) ... Put(val), the Gets() are
equivalent. i think, serialized objects should be readable on most
plattforms, i only need the big 3 (linux/mac/win, alphabetical). the
only problem is, that i have to cast before the shift to unsigned char,
so the bit-identical is very important because i can only test on 2
plattforms...

cheers, chris

re: int8_t/uint8_t

Chris Forone wrote:They are twos complement, *if they exist*. On platforms with ones
complement, or 9 bit bytes, you're toast.
They are all the same size on a given platform. Was that your
question?
The best way to be platform independent is to define the transport
format separately. They you have to implement this on each platform,
in a platform dependent way.


Bo Persson

re: int8_t/uint8_t

On Jul 3, 4:21*am, joseph cook <joec...@gmail.comwrote:There are no endian issues to consider with 8-bit data. So the quick
answer is "yes", int8_t and uint8_t (unlike "char") are guaranteed to
use two's complement integer representation.

Greg

re: int8_t/uint8_t

On Thu, 03 Jul 2008 08:30:22 +0200, Chris Forone <4one@gmx.atwrote
in comp.lang.c++:
People tend to say that, but they're wrong, of course. The exact
width integer types aren't actually part of standard C++ yet, but they
soon will be.

As defined in C, int#_t is required to be a signed integer type of the
specified number of bits with no trap representations and no padding
bits. It uses 2's complement for representing negative values.

But uint#_t types only hold unsigned values. They cannot represent
negative values, so they aren't ever 2's complement, 1's complement,
or sign and magnitude. These three things only apply to signed
integer types, and never to unsigned integer types.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html