Re: By value-result vs by reference

In article 94-04-167 nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
>hbaker@netcom.com (Henry G. Baker) writes:
>: Baker, H.G. "How to Steal from a Limited Private Account -- Why Mode IN
>: OUT Parameters for Limited Types _Must_ be Passed by Reference". ACM Ada
>: Letters XIII,3 (May/June 1993), 91-95.


>I'm familiar with the article but the example is so contrived I have a
>hard time believing anyone would accidently write code like that. I've
>never seen a convincing example showing how someone might accidently
>write an "erroneous" program, only how you can write one on purpose.


I have two responses. First, if you are the author of the package which
exports the limited private type (Ada's most opaque kind of abstract data
type), and one of your customers manages to trash one of your supposedly
protected resources, you're going to be pretty upset. (How the **ll did
_that_ happen?) If something very bad happens, and the 'black box'
recorder finds that your data type instance was trashed, the blame will
fall on you. So the protection offered by Ada's abstract packaged type is
actually a dangerous illusion. As a result, a competent system designer
is forced to offer hardware protection as well, which increases system
cost for every instance. It would have been better for Ada to have done
it right the first time.


My second response is that accidently aliasing two 'in out' parameters is
quite likely, and nearly impossible for a programmer to check for. The
simplest example I can think of involves mathematical objects like
bignums, short vectors (x,y,z) or small matrices. You develop a library
of routines which utilize 'in out' parameters for 'efficiency' reasons.
Later on, someone needs to call a routine like 'matrix_multiply' to
compute the square of a matrix. Crash! Much, much more subtle things can
happen if one argument is aliased to a subportion of another.


Perhaps the paper didn't go far enough. It only showed the _possibility_,
not the _probability_, of this sort of problem.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.