rbk@sequel.UUCP (09/29/83)
Has anyone ever thought about the problems of exchanging binary
data-structures between two different machines/compilers? (of course
you have!) I had a thought about "packed" structures (borrowing an
idea from Pascal) that might help some of the problem:
struct garf {
char g_char;
short g_int;
char g_char2;
long g_long;
};
This has "holes" in it that will align differently on differnet machines
(eg, VAX vs PDP-11). Suppose there was "packed struct", such as:
packed struct garf g_var;
That insisted the structure have all possible holes squeezed out of it;
on a VAX, NS16k, 8086/286 all holes go away; on PDP-11 and 68K (I
think) you still have short/int requiring even alignment. This should
be easy for compilers to implement, and doesn't cost the program
anything unless used.
The binary-data-structure problem is a tough one in general. "Packed"
doesn't solve the problem completely (and doesn't address the byte-order
problem at all), but might help some. Clearly if *you* get to specify the
structure (and you are careful) the problem is minimized without this;
however, there are many pre-existing data-structures out there that you
have to live with.
Comments? Any other thoughts? Flames >& /dev/null, please...
--
Bob Beck
Sequel Computer Systems
...ogcvax!sequel!rbk
(503)627-9809asente@decwrl.UUCP (Paul Asente) (09/30/83)
Packed structures sound like a great idea. Earlier this summer I had to deal with a device that required certain 32-bit integer quantities to be aligned on 16-bit boundaries in its command packet format. The solution I ended up coming up with is one of the all-time great kludges of my life (involving storing the longs as arrays of 2 shorts and doing pointer coercion all the time) and everything would have been much easier if I could have just said to pack the array the way I specified it! -paul asente (decvax, ucbvax, allegra, ihpn4)!decwrl!asente
henry@utzoo.UUCP (Henry Spencer) (10/05/83)
Actually, all holes *don't* necessarily go away if you were to declare
something "packed" to a 16032 compiler that understood the notion.
The 16032 cannot guarantee to do copy-on-write memory management properly
unless things are aligned. (The problem is that an unaligned data item
which crosses a page boundary from a read-write page to a read-only page
may get its first part stomped before the MMU realizes that the second
part is not writeable.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry