Different sizes of long int on different machines.
Quote:
>(Pl. note: This is my first ever post to a newsgroup outside my campus,
>so please bear with any mistakes. Any suggestions are also welcome.)
> I had a problem with a program I wrote (in C++ actually, but this is
>irrelevant). The program crypted a file and used a checksum which was
>declared as a long int. It worked separately on a DEC Alpha and a 486
>running Linux, i.e files crypted on one m/c could be decrypted there,
>but "cross-usage" used to give a checksum error. After a lot of trials,
>I found this was because of the different sizes of long int. Can anyone
>tell me how to declare an int-like data type having say 8-bytes which
>will work on both. (is such a thing possible?) .
Firstly C doesn't guarantee anything beyond a 32 bit integral type. Since
your code worked on Linux this is probably enough for you. For the sort
of thing you're doing I suggest you take a look at unsigned long as opposed
to long. Unsigned types are well-defined (and therefore portable) semantics
in the case of overflow and have a simple correspondance between bit pattern
and value.
You can't guarantee to get a particular size of int in C. For example
implementations exist where the integer sizes are not a multiple of 8 bits.
However what you are guaranteed is that, say, unsigned long can represent
values up to at least 4294967295 which means it has at least 32 bits.
To write portable code simply make it use the low order 32 bits of an
unsigned long. For most operations you can simply ignore any higher order
bits, you just have to be careful when comparing/testing, dividing, right
shifting or outputting values.
The other thing you have to be careful about is byte order. If you are
accessing the bytes of longer types directly C doesn't specify what order
they are stored in. I believe both the Alpha and x86 archetectures are
little endian (low order byte at lowest memory address) so compatible in
this respect but there are plenty of big-endian archetectures out there
(e.g. 68000, Sparc).
--
-----------------------------------------
-----------------------------------------
