comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@earthlink.net>
Subject: Re: Unconstrained type Unchecked_Deallocation
Date: 2000/04/12
Date: 2000-04-12T00:00:00+00:00	[thread overview]
Message-ID: <38F4D388.31821B3@earthlink.net> (raw)
In-Reply-To: 8cqjjb$muu$1@nnrp1.deja.com

Robert Dewar wrote:
  
> Your discussion boils down to worrying about a class of
> programmers who have the following characteristics.
> 
> 1. They would not dream of looking in a body, and taking
> liberties with information derived therefrom.
> 
> 2. They will look at an unchecked conversion in the spec and
> feel free to do stupid things.

  Yep, on a large project, if there is an unchecked conversion in the
interface, programmers
will assume that it is part of the interface and can be treated as
such.  These same programmers
may never have the opportunity to look at the corresponding body, which
may be written by a group at a different location, or even a different
company.  In fact, I have seen unchecked perversion where the specs were
common, and the bodies were written by two different companies several
thousand miles apart.  Moving to a different platform was a killer...
 
> OK, maybe there are such programmers, but I have not met them.

  The luxury of being an academic. ;-) That smiley is because Robert
Dewar has spent as much time in the trenches as I have.  I just used to
get called in on the really bad cases.  I literally can't tell you how
many times I have been called in to declare the corpse dead--and yes,
there have been a few times when it wasn't.  If I can I'd like to write
a paper on how to tell that a software project is dead.  In one
sentence, if fixing a bug will on average introduce at least one new
bug, stop.  The trick is to be able to determine that ahead of time, and
stop earlier.  (Or even on time.  It is a characteristic of failed
software projects that the quality of the bug report database is poor.)

> I meet really two classes of programmes in this kind of respect.
 
> 1. Those who are careful, and know that it would be folly to
> depend on the representational equivalence implied by an
> unchecked conversion, whether or not it is in the spec or the
> body.

    But would never dream of putting the Unchecked_Conversion in the
visible part of the package...
 
> 2. Those who will do what they like, regardless of what is nice,
> and will not hesitate a moment to draw the same (bad) conclusion
> from an unchecked conversion in the body as in the spec.

    But to make use of the fact, they often have to put in their own
instances of Unchecked_Conversion and get caught that way.
 
> I think trying to make this out as an important methodological
> issue is bogus. After all, if you have a function in the spec
> whose spec is that it convers from integer to address by the
> moral equivalent of unchecked conversion, then you can draw
> evil conclusions just from this spec. I cannot imagine some
> wonderful high level semantic description of this conversion
> that is at an abstraction level different from unchecked
> conversion (assuming a reasonable implementation thereof).

     No, the conclusions that you can draw from the function in the spec
are not evil.  If for example the body of a visible conversion function
is an instance of Unchecked_Conversion from Integer to System.Address,
and the program is moved to a different platform where the two have
different sizes, then it will usually be possible to replace that body
without changing the semantics.  (Of course there will normally be more
than one operation in the package that needs to be rewritten.  But
still, you are within one package body, and don't have to look
throughout the program.)




  reply	other threads:[~2000-04-12  0:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-05  0:00 Unconstrained type Unchecked_Deallocation Andy Askey
2000-03-06  0:00 ` Ted Dennison
2000-03-06  0:00   ` tmoran
2000-03-06  0:00   ` John English
2000-03-06  0:00     ` Ted Dennison
     [not found]     ` <38C566CE.6283C0AD@rational.com>
2000-03-08  0:00       ` Robert Dewar
2000-03-08  0:00         ` Larry Kilgallen
2000-04-05  0:00         ` Robert I. Eachus
2000-04-06  0:00           ` Robert Dewar
2000-04-09  0:00             ` Robert I. Eachus
2000-04-09  0:00               ` Robert Dewar
2000-04-12  0:00                 ` Robert I. Eachus [this message]
2000-04-06  0:00           ` P. S. Norby
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox