Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cisden.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!hao!nbires!boulder!cisden!aburt
From: aburt@cisden.UUCP (Andrew Burt)
Newsgroups: net.lang.c
Subject: Un-alignment in structures
Message-ID: <243@cisden.UUCP>
Date: Wed, 13-Mar-85 16:41:22 EST
Article-I.D.: cisden.243
Posted: Wed Mar 13 16:41:22 1985
Date-Received: Sat, 16-Mar-85 05:39:27 EST
Reply-To: aburt@cisden.UUCP (Andrew Burt)
Organization: ConTel Information Systems, Denver
Lines: 87

I don't recall seeing this hashed out in here so I thought I'd see what
the general reaction is.

Recently I've had to work around a machine dependency (on several machines)
that it strikes me C should allow me to avoid.  After all, C is
supposed to be portable and "low" level at the same time, right?  The
problem is in structure padding.  I fully realize why when I say:
	
	struct foo {
		int	i;
	};

	struct bar {
		char		c;
		struct foo	f;
	};

I may get an internal representation with c having offset 0 from the
beginning of bar and f.i having offset, say, 2 (or 4 or ...) with a byte
in between them not being used.  I also understand the same thing
happening if struct foo is:

	struct foo {
		char	c;
	};

However, it would be useful (I didn't say efficient, mind you) if
I could say something like
	
	struct bar {
		char			c;
		unaligned struct foo	f;
	};

with the effect that f.c would have an offset of 1 from the beginning
of struct bar; or f.i -- yes, an int at an odd address.  I mean this
regardless of how it's implemented.  E.g. if I did

	struct bar b;
	b.f.i = 7;

I would expect code to be generated analogous to

	int tmp = 7;
	bcopy(&tmp, &b.f.i, sizeof int);

Clearly this is not what I want for a default, since most code really
doesn't care about padding in the middle of structures (or so I would
imagine).  But this would be wonderful for porting code and especially
data files to other architectures.  Not to mention dealing with
non-unix machines:  I'm working on a large piece of comm software that
has to speak to a large variety of machines on a lan, all of which get
very upset when I

	write(fd, &b, sizeof(struct bar));

and they get nifty-keen nulls in the middle of it all.  If perhaps I could
choose how to organize my structures such that I had, say, two characters
followed by that int (or whatever I need so that I don't get any padding)
I wouldn't mind so much.  But the case here is that I have to talk the
language of the remote system, not vice versa -- and it says "char followed
by int" (for example).  Since I have no choice, I am writing out a string,
doing the bcopy's into it with #defined offsets.  Not pretty.

(The variable length fields I get back are another can of worms entirely,
but I wouldn't even think of suggesting that C should generate code knowing
which bytes imply what structure sizes to use.  After all, I need something
to do to earn my paycheck :-)

If we wanted to get carried away, we could ask for structure assignments
between aligned and non-aligned structures with the same elements (the
difference being the latter has padding).  Maybe something like this...

	struct bar b;
	unaligned struct bar ub;

	ub = (unaligned) b;

Imagine how easy it would be to port a data file.

In terms of practicality, I wouldn't want this put into C or the ANSI standard.
I was thinking more along the lines of C++, or if it's too late for that,
C+=2.  Certainly the language has to grow or it will stagnate.
-- 
Andrew Burt
Contel Information Systems
{ucbvax!nbires, seismo!hao!nbires, boulder}!cisden!aburt