[comp.sys.mac.programmer] Question: Putting structs in resources

dce@smsc.sony.com (David Elliott) (09/05/90)

As a Unix programmer, I've learned that it is usually a bad idea
to write the contents of a struct to a file, since there is no
way to know if every machine can read it back correctly.

As you may already know, data written on a big-endian machine,
such as a 680x0, will have a different format than on a little-endian
machine, such as a Vax or a DEC MIPS-based machine.

In addition, machines may have different alignment rules.  For example,
a Sun 3 (68020) allows a long (32 bit integer) to be aligned on
half-word (16-bit) boundaries, whereas the SPARC-based machines require
full-word alignment.  As a result, a struct written on a Sun 3 may have
to be handled specially when read back on a Sun 4 (a typical method is
to define the struct as containing shorts and then convert the shorts
to longs by copying).

Is it common practice to read and write structs as resources on the
Mac?  If so, is there any worry that these resources will not be
compatible if Apple were to go to a platform with different alignment
restrictions (I assume byte order isn't an issue)?  If not, what
is the recommended procedure for putting lots of data into a resource
and getting it back easily?

-- 
...David Elliott
...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
...(408)944-4073
...Krusty says: Give a hoot, read a book!

hawley@adobe.COM (Steve Hawley) (09/06/90)

In article <1990Sep5.145717.13291@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes:
>Is it common practice to read and write structs as resources on the
>Mac?  If so, is there any worry that these resources will not be
>compatible if Apple were to go to a platform with different alignment
>restrictions (I assume byte order isn't an issue)?  If not, what
>is the recommended procedure for putting lots of data into a resource
>and getting it back easily?

OK - as far as reading/writing structures is concerned, you should have no
problem doing this on the Macintosh platform, since they have done remarkably
well in maintaining compatability.  Famous last words, but I say go ahead
because a change in the operating/file system that causes a change in byte
ordering will break a HUGE number of applications --more than such a change
could possibly help.

The biggest danger to you is your compiler/interpretter changing the way it
allocates structures.

If you're really terrified, remmeber that you can always break the structure
down to the byte level (since bytes are bytes, right?) piecemeal from the
elements and put the resulting bytes into a buffer, then ship it out to disk.
This is of course, tedious and slow (but surely not slower than the bottleneck
of your bulk storage).

As far as "putting lots of data into a resource", please do not stumble into
the habit of using the resource fork of a file as a pigpen for data.  The
reason being that
	1) any custom data format will be managed much more efficiently by you
	2) if you try to write an application that writes into its own resource
	   fork, you will have endless problems working with a fileserver.

Remember, the data fork of a file is for data.

Steve Hawley
hawley@adobe.com

-- 
"I can always telephone, but I can't tell it much."
	-Roy Blount

pepke@gw.scri.fsu.edu (Eric Pepke) (09/07/90)

In article <1990Sep5.145717.13291@smsc.sony.com> dce@smsc.sony.com (David 
Elliott) writes:
> Is it common practice to read and write structs as resources on the
> Mac?

Yup.

>  If so, is there any worry that these resources will not be
> compatible if Apple were to go to a platform with different alignment
> restrictions (I assume byte order isn't an issue)?

Apple has done a rather remarkable job of keeping compatibility across the 
line.  So far the alignment on newer machines has become more lax rather 
than more restrictive.  Even if this were to change, the ability to read 
structures from resources is so basic that compiler writers would have to 
build in transparent compatibility measures.

Eric Pepke                                    INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   pepke@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.