Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!smoke!4596::GUTHERY%slb-test.csnet@CSNET-RELAY.ARPA
From: T-RELAY.ARPA>@brl-smoke.ARPA
Newsgroups: net.lang.c
Subject: Phooey on Portability
Message-ID: <5225@brl-smoke.ARPA>
Date: Wed, 5-Nov-86 21:05:56 EST
Article-I.D.: brl-smok.5225
Posted: Wed Nov  5 21:05:56 1986
Date-Received: Thu, 6-Nov-86 00:55:21 EST
Sender: news@brl-smoke.ARPA
Lines: 28

I'd like to get at the byte stored in memory location 6.  So I just

struct {
	char	byte;
	int	word;
	long	longword;
} *MEMORY;

main(){char mybyte = 6->byte;}

No sweat.  Works like a charm daily.  But what do I do on segmented memory
systems like the PC?

main(){char mybyte = 0:6->byte;}

Not likely.  So much of the squirming about lvalues and chars and the like
comes from both wanting to be memory system independent and close the metal.
Why don't we just say that every compiler writer should include a section
in the manual called "Memory Model" wherein the following things are defined?
I personally want to snuggie right up the memory system in my C programs.
That's why I chose C!  I really have plenty to worry about besides machines
I'm NOT trying to program.  I guess what I'm saying is that until we can
create well-engineered, reliable code for one machine why are we wasting
our time worrrying about doing it for all machines at once?  In other words,
portability is mostly a red herring.  Good code on one machine beats
bad code on many machines every time.

"Executable requirements wouldn't."