Path: utzoo!attcan!uunet!know!cs.utexas.edu!swrinde!ucsd!usc!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.lang.misc
Subject: Re: REFs or aliases? (was Re: C's sins of commission)
Message-ID: <1990Nov5.080320.28215@tkou02.enet.dec.com>
Date: 5 Nov 90 08:03:20 GMT
References: <8960021@hpfcso.HP.COM> <4667@lanl.gov> <1990Nov2.002843.28959@Think.COM>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 28

In article <1990Nov2.002843.28959@Think.COM> barmar@think.com (Barry Margolin) writes:

>Here's an example of code that uses pointers in a way that I don't think
>arrays can substitute.  Something like this appeared in code that a friend
>wrote several years ago:
>char auto_buffer[BUFSIZ]; char* bufp; int in_size;
>if ((in_size = input_size()) < BUFSIZ)
>	bufp = auto_buffer;
>else
>	bufp = malloc (in_size);
>get_input (bufp);
>...
>if (bufp != auto_buffer)
>	free (bufp);

PL/I had CONTROLLED variables 26 years ago too.  Although this is another
use of an ugly example, it remains a valid existence proof.  The generated
machine code is full of pointers and gotos (as for all programs), but the
source code isn't.

Uh, Mr. Margolin, you justified this code by the relative speed of stack
accesses vs. heap accesses.  Is that true even when both accesses are done
by dereferencing your bufp variable?  (And the equivalent in PL/I,
dereferencing an entity that is transparent to the programmer.)
-- 
Norman Diamond, Nihon DEC    diamond@tkov50.enet.dec.com
                                    (tkou02 is scheduled for demolition)
We steer like a sports car:  I use opinions; the company uses the rack.