[comp.lang.c] Phooey on Portability

throopw@dg_rtp.UUCP (Wayne Throop) (11/09/86)

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

throopw@dg_rtp.UUCP (Wayne Throop) (11/10/86)

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

billc@blipyramid.BLI.COM (Bill Coffin) (11/13/86)

People that think portability is not an issue in a particular piece
of code almost always face, sooner or later, a nasty surprise.