[comp.lang.c] Help with C between 68000 & 80286

lodzins@pilot.njin.net (Dean Lodzinski) (08/06/90)

I am pretty new to the C language and need some help with converting
chars, int, long int, etc.  I have numerous datafiles that were
created using Mark Williams C on a 68000 machine.  I am trying to read
in the data files using Power C 2.0 or Quick C 2.5 on my AT.  Since
Intel reads the bytes differently, I can't directly use the data.
It appears I have successfully made functions to convert int and long
int to the correct format and the numbers are correct.  I am still
having problems with other types.  If anyone can point me in the right
direction or give me any information, I would appreciate it.  If I
didn't explain this clearly enough, I am sorry, but it is confusing to
me.  Thanks.
-- 

Dean Lodzinski         DEAN_L@TURBO.Kean.edu, lodzins@pilot.njin.net
47 Mercury Circle      csra19@TURBO.Kean.edu or D.LODZINSKI on GEnie
South Amboy, NJ  08879 Dean Lodzinski on Hologram Inc., FNET Node 133, 
USA                    at 201/727-1914 (1200/2400/9600)

pl@etana.tut.fi (Lehtinen Pertti) (08/06/90)

From article <Aug.5.14.43.00.1990.26343@pilot.njin.net>, by lodzins@pilot.njin.net (Dean Lodzinski):
> 
> It appears I have successfully made functions to convert int and long
> int to the correct format and the numbers are correct.  I am still
> having problems with other types.
>
	In addition to byte order, also alignment can cause problems.

	For example

	struct x {
		int i;
		char x;
		int z;
	};

	is possible to allocate:

	long, byte, dymmy-byte, long	( 68000 32-bit compiler )
	word, byte, dummy-byte, word	( 68000 16-bit compiler )
	word, byte, word		( 80286 16-bit compiler )

--
pl@tut.fi				! All opinions expressed above are
Pertti Lehtinen				! purely offending and in subject
Tampere University of Technology	! to change without any further
Software Systems Laboratory		! notice

scs@adam.mit.edu (Steve Summit) (08/07/90)

In article <Aug.5.14.43.00.1990.26343@pilot.njin.net> lodzins@pilot.njin.net (Dean Lodzinski) writes:
>I have numerous datafiles that were
>created using Mark Williams C on a 68000 machine.  I am trying to read
>in the data files using Power C 2.0 or Quick C 2.5 on my AT.  Since
>Intel reads the bytes differently, I can't directly use the data.

It may be best to convert the files to ASCII (using printf %d,
%e, etc.), transport them, and then read them in (or convert them
back) with scanf and/or atoi, atol, atof, etc.  You may find
yourself wishing that the data files had been written in a text
format originally (I certainly would, if I were stuck with this
problem).  ASCII text data files are usually preferable for this
very reason (and for several other reasons).  Some will claim
that ASCII storage, with its inherent formatting on output and
parsing on input, is too inefficient, but this is often not true
in practice.

I think I'll add this to the FAQ list; it comes up all the time.
(Worry not, efficiency hackers, I'll try not to editorialize in
favor of ASCII storage too much.)

                                            Steve Summit
                                            scs@adam.mit.edu

libes@cme.nist.gov (Don Libes) (08/07/90)

In article <1990Aug7.023429.19786@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>back) with scanf and/or atoi, atol, atof, etc.  You may find yourself wishing
>that the data files had been written in a text format originally (I certainly
>would, if I were stuck with this problem).  ASCII text data files are usually
>preferable for this very reason (and for several other reasons).  Some will
>claim that ASCII storage, with its inherent formatting on output and parsing
>on input, is too inefficient, but this is often not true in practice.

>I think I'll add this to the FAQ list; it comes up all the time.  (Worry not,
>efficiency hackers, I'll try not to editorialize in favor of ASCII storage
>too much.)

Please add that there is an ISO standard for machine-independent data
storage, namely 8825 (ASN.1 Basic Encoding Rules) and there is a
public-domain implementation of it along with ASN.1 (ISO 8824) itself.

In my experience, ASCII is ok only for the simplest of applications.
As you say (and I agree), inefficiency is not the big problem.  The
big problem is that users have to rediscover using trial and error all
the nonobvious problems that ASCII representation presents.  Do you
handle quotes?  Whitespace?  \0?  Structs?  Linked-lists?

I'm not saying these are impossible to solve with ASCII.  I'm just
saying the likelihood is high that most people will produce ad hoc
buggy solutions, and that leads to a waste of their time.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes