Phooey on Portability (apology and re-explanation)

[Wayne Throop]

> throopw at 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      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw