SEO

Gentle People:

I have found an interesting Endinness issue.

On both Solaris 8 Sparc and Solaris 8 IA32
machines when I read the same file sequentially
using getc() and I get different results in byte
ordering because of the Big Endian (Sparc) versus
Little Endian (Intel) file system data organization.

Question is there any way to automatically
compensate for this with getc??? Or more obviously
do I just have to rewrite the software application
to compensate for this?

Thanks for the help
Thomas Dineen

There is no way you can automatically compensate for this. It depends
entirely on the data contained in the file.

If all the data are 1 byte wide, like in an ascii file, there is
nothing you need to do, it is already correct for. If it contains only
2 byte shorts, then you need to swap them pairwise, if they are 4 byte
ints, you need to do quad swapping, etc. Frequently the data is a mix
of data types, and unless you know exactly how it is laid out, you
can't work around the problem in any simple manner.

This has nothing to do with the filesystem type, it is only a problem
of the file content.

In article <[email protected]>,
Thomas Dineen <[email protected]> writes:
> Gentle People:
>
> I have found an interesting Endinness issue.
>
> On both Solaris 8 Sparc and Solaris 8 IA32
> machines when I read the same file sequentially
> using getc() and I get different results in byte
> ordering because of the Big Endian (Sparc) versus
> Little Endian (Intel) file system data organization.

If you read the same file sequentially using getc(),
you won't see any difference due to endianism.
Endianism only comes into play when you are dealing
with multiple byte quantities, but getc() only gives
you a byte at a time, and behaves identically on
little and big endian systems.

> Question is there any way to automatically
> compensate for this with getc??? Or more obviously
> do I just have to rewrite the software application
> to compensate for this?

You'll have to describe more accurately what the
problem is.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]