On Mon, 08 Dec 2003 23:19:16 GMT, CBFalconer <cb********@yah oo.com>
wrote in comp.lang.c:
Kevin Goodsell wrote: CBFalconer wrote:
If you adhere to the C standard, you should have no problems with
any of those, barring the use of binary files created or used by
other systems. That you can avoid by using text.
Could you explain what specific problems you are referring to with
respect to binary files?
For example, endianness, sizeof various entities, value of
CHAR_BIT, etc.
I'm curious, Chuck, because I know you're a long time embedded systems
programmer with experience on many different architectures, as I am.
Have you ever worked on a platform where CHAR_BIT was NOT 8? I've
done some Analog Devices SHARC work where CHAR_BIT was 32, and I'm
doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16.
If you have worked on platforms where CHAR_BIT was greater than 8,
have they always had signed and unsigned char having the same
representation as signed and unsigned int (if not also signed and
unsigned long)?
Note that many standard functions, particularly all FILE * streams,
are impossible to implement on a platform where UCHAR_MAX == UINT_MAX,
since all file input if built on fgetc(), which can return any
unsigned character value from 0 to UCHAR_MAX, and EOF which must be a
negative integer and have a recognizably different bit pattern from
the above.
As for dealing with data internally on platforms with CHAR_BIT > 8,
it's not really all that hard. All the code in my chapter of C
Unleashed is "CHAR_BIT > 8" safe, because you only use the 8 least
significant bits an unsigned char and ignore anything else.
In the real world, I recently wrote both ends of a parser/formatter
for a proprietary CAN bus protocol. CAN messages (as you probably
know, but others might not) contain between 0 and 64 bits of data,
packed into 0 to 8 octets of 8 bits each.
My parser and formatter can pack and unpack various 8, 16, and 32 bit
values from any possible starting point in the data field of such a
packet into a signed or unsigned 8, 16, or 32 bit data object.
Since the processor on one side of the protocol was a TI DSP with
CHAR_BIT 16, it was written with "CHAR_BIT > 8" portability in mind.
The resultant source code compiles and runs properly both on the DSP
and on the other end of the CAN bus, where the ARM processor does have
8 bit character types.
There is only one tiny bit of surplus code to achieve that
portability. At one point there is an expression where an unsigned
char value is updated like this:
uc = (uc << 2) & 0xff;
....the mask is unnecessary when CHAR_BIT is 8 but is necessary on the
DSP because other parts of the code require all bits above 8 in the
unsigned char (if any) always be 0.
The value of CHAR_BIT is not much of a deterrent to portable code if
you give it a little thought and avoid using more than 8 of them even
when they are available.
--
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++
ftp://snurse-l.org/pub/acllc-c++/faq 
