Phooey on Portability

[Wayne Throop]

> (poster unknown... "From:" field truncated)

First a small nit.

> 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.  I suppose this might work on SOME
mickey-mouse compiler/machine/OS combinations, but just LOOK at
these gawd-awrfil questionable assumptions!

  - small integers cast to pointer type gives reasonable results
    (by no means guaranteed).
  - struct fields are a global namespace
    (not even standard C anymore)
  - conversions of int to pointer types will be implied by the ->
    operator as needed (definitely not standard C)

and probably a zillion more I'm missing!  Gad-zooks!

> 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.

Well, two points I'd like to raise.  First, we *CAN* (in some cases)
create well-engineered, reliable code for "all machines at once" even
now.  It's just that the above (let's be kind here) pig swill isn't a
good example of how to do it.

Second, about portability being a red herring...  well, come back and
tell me that after you've had to port all the software you've written
across three or four generations of machines (due to obsolescence of the
older ones) as I've had to do, and THEN maybe I'll believe you.  But
probably not.  And it's likely to get worse rather than better, what
with shorter hardware design cycles, RISC, and so on and on.

So there, you... you... smug whippersnapper you!

--
"Kids these days..."
"Yeah, not like the old days, when you could take 'em out and
 BEAT SOME SENSE INTO 'EM!!!!!"
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw