On Jun 15, 3:57 pm, Javier <jjeron...@gmail.comwrote:
I'm recoding a library that made a few months ago, and now that I'm
reading what I wrote I have some questions.
My program reads black and white images from a bitmap (BMP 24bpp
without compression). It has it's words and dwords stored in little-
endian, so I do a conversion to big-endian when reading full words or
dwords.
I have done this because my system is big-endian.
But now... what if one compiles the library in a little-endian system?
The endian-ness of the internal represention shouldn't make a
difference. You deal with values, not with physical
representation. Basically, to read little endian, you use
something like:
uint32_t
read( uint8_t const* buffer )
{
return (uint32_t( buffer[ 0 ] ) )
|| (uint32_t( buffer[ 1 ] ) << 8)
|| (uint32_t( buffer[ 2 ] ) << 16)
|| (uint32_t( buffer[ 3 ] ) << 24) ;
}
Works regardless of the byte order. (I've seen at least 3
different byte orders for 32 bit integers.)
And... I use char (which I have readed that is equal to unsigned short
int) as 'byte'.
That's generally not true. On most machines today (there are a
few exceptions), char is 8 bits; short must be at least 16.
Also, very often, char is signed. I tend to avoid it for that
reason as well; shifting signed values doesn't always work as
expected.
And this is the other question: is sizeof(char) a 'byte' always?
That's the definition in the standard: char is a byte.
Sizeof(char) is guaranteed to be 1. As I said above, on most
machines today, it is 8 bits. The standard requires at least 8
bits, although in the past, 6 and 7 bit bytes were common (as
were 9 and 10 bits). From what I have heard, some DSP define
char to have 32 bits, with all of the integral types having a
sizeof 1. Also legal.
How can I define byte, word and dword (8, 16, 32 bits) without making
the asumption that are sizeof(char) is a byte (8 bits).
How portable do you want to be? C has a header, <stdint.h>,
which conditionally defines a certain number of integral types
with fixed, exact length, i.e. uint8_t is an unsigned integral
type with exactly 8 bits, int32_t is a signed, 2's complement
integral type with exactly 32 bits, etc. If the underlying
hardware doesn't support the type, it is not defined.
Regretfully, support for this header seems to be rather spotty.
But it's not too difficult to knock up your own version; put it
in an isolated, system dependant directory, where you know that
you have to adapt it each time you port to a new machine.
As I said, however, the presence of the definitions are
conditionned on the existance of the actual types. Not every
machine around today uses 8 bit bytes, and not every machine
uses 2's complement. Still, for many applications, portability
to only those machines that do is a quite acceptable
restriction.
(And BTW: a word is normally 32 bits, and a dword 64. 16 bits
is a hword, at least in IBM-speak.)
--
James Kanze (Gabi Software) email:
ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
