Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <hbakerCxL95y.8L3@netcom.com>, hbaker@netcom.com (Henry G. Baker)
says of the bounded error that results from aliasing subprogram
variables: 

|>                     But this policy is still a crock, especially for
|> Ada 'limited' types, because the definer of the type has lost control
|> of the type.  The 'textbook' definitions of prototypical limited types
|> such as 'bank accounts' are no longer safe in the presence of such
|> equivocation.
|>
|> See "How to Steal from a Limited Private Account--Why Mode INOUT
|> Parameters for Limited Types MUST be Passed by Reference".  Ada
|> Letters XIII, 3 (May/June 1993), 91-95.  This paper is also in my ftp
|> directory.

Henry, you seem to be envisioning some sort of adversarial relationship
between the writer of a limited private type and the client who uses the
type.  It makes more sense to think of the limited private type as an
appliance that is used by the client.  If you use it properly, it is
guaranteed to work; if you abuse it, you void the warranty.  The client
who uses the limited private type in a way that violates the rules of Ada
is the one responsible for the fact that the properties of the
limited-private type are violated, and it is his program that breaks.

If your point is simply that a "bounded error" can have consequences more
wide-ranging than one might suspect from the innocuous-looking lists of
possible outcomes (use the old parameter value, use the new parameter
value, or raise Program_Error), then your point is well taken.

It's still a step forward from Ada 83, where the same rule violation is
considered erroneous, which means in effect that the underlying abstract
machine is broken and NOTHING is guaranteed.

--
Norman H. Cohen    ncohen@watson.ibm.com