Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!hp-sdd!ncr-sd!ncrcae!ece-csc!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: comp.lang.c Subject: Re: Phooey on Portability (apology and re-explanation) Message-ID: <691@dg_rtp.UUCP> Date: Mon, 10-Nov-86 11:03:33 EST Article-I.D.: dg_rtp.691 Posted: Mon Nov 10 11:03:33 1986 Date-Received: Tue, 11-Nov-86 02:13:44 EST References: <5225@brl-smoke.ARPA> <687@dg_rtp.UUCP> Lines: 60 Summary: Even so, STILL double Phooey on non-portability! > throopw@dg_rtp.UUCP (Wayne Throop) >> (poster unknown... "From:" field truncated) Hmpf. After a weekend of reflection, looks like I should raise my time-limit-between-reading-and-posting again. I'll embarrass myself by overreacting less often, I expect. But despite the fact that I expressed myself in a contentious and juvenile fashion, I think I did have a couple of points to make. I just made them poorly and emotionally, and I hereby apologize to the original poster in this subject line. I'll try to restate them more cooly, and beg you kind folks' indulgence. >> I'd like to get at the byte stored in memory location 6. So I just >> struct { char byte; } *MEMORY; >> main(){char mybyte = 6->byte;} > Gag. Choke. Retch. Puke. Awright, awright. I SAID I overreacted, right? Nevertheless, if you really want to synthesize pointers from raw bits (and dereference them), a much better way to do it is this: mybyte = *((char *)6); This is, of course, still completely non-portable, but relies less on what appears to be a really (c'mon, think up a nonjudgemental phrase Throop... uh... uh...) UNIQUE implementation of the C language. The point here is that even future revisions of the self-same compiler seem likely to me to break such fragile assumptions. On the other hand, the original poster used this example to make a very good suggestion: that every implementation of C give details of architecture and machine specific extensions and assumptions made by the compiler. I just found the "6->byte" solution so... unaesthetic as to make me... well... upset. >> 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. > [bitch, bitch, bitch, insult, insult, insult] Ok, ok, so my breakfast disagreed with me that day. But seriously... machine obsolescence alone makes portability much, much more than a red herring. And more: many issues that are normally jeered at as being "silly portability quibbles" are really silly MODULARITY quibbles or silly LANGUAGE DEFINITION quibbles, and these quibbles apply even if one never intends to run the code on another machine, ever. (There, that wasn't so hard, was it Throop? And remember Throop, raise your time limit, y'hear? Your face'll be much less red and much less often, I garr-ron-TEE.) -- There is nothing in the world more helpless and irresponsible and depraved than a man in the depths of an ether binge. --- Hunter S. Thompson -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw