Version 1.1 of ais/ai-00141.txt

Unformatted version of ais/ai-00141.txt version 1.1
Other versions for file ais/ai-00141.txt

!standard B.3 (00)          97-11-14 AI95-00141/06
!class confirmation 96-11-16
!status WG9 Approved 97-11-14
!status ARG Approved (subject to editorial review) 8-1-1 97-04-11
!status work item 2-5-3 96-10-07
!status work item 96-05-08
!status received 96-05-07
!priority High
!difficulty Hard
!subject Exceptions in Interfaces.C and its Children
!summary 96-11-16
When passing a null value of type Pointer to one of the subprograms in Interfaces.C.Pointers:
Value, Copy_Terminated_Array, Copy_Array, and Virtual_Length raise Interfaces.C.Strings.Dereference_Error.
"+", "-", Increment and Decrement raise Pointer_Error.
!question 96-11-16
The package Interfaces.C.Pointers contains various subprograms with parameters of type Pointer. For all these subprograms, an exception must be raised when one of the Pointer parameters is null. However, there seems to be some hesitation as to which exception must be raised:
Value, Copy_Terminated_Array, Copy_Array and (maybe) Virtual_Length must raise Interfaces.C.Strings.Dereference_Error.
"+", "-", Increment and Decrement must raise Pointer_Error.
While this semantics is well-defined (except perhaps for Virtual_Length), it seems quite strange that two exceptions are involved for very similar programming errors. It seems also strange that Interfaces.C.Pointers raises an exception which is declared in Interfaces.C.Strings. What was the point of declaring the exception Pointer_Error if it's not used everywhere? What is the intent?
!response 97-10-27
Virtual_Length is defined in terms of Value, and so raises Dereference_Error if Ref is null.
For all the others, an explicit statement in the RM gives the exception to be raised.
Dereference_Error is intended for dereferences of a null pointer, whereas Pointer_Error is intended for address arithmetic on a null pointer.
It may seem strange that an operation from Interfaces.C.Pointers raises an exception which is declared in Interfaces.C.Strings. However, this is not sufficient justification for changing the clear wording of the RM. It just means that the body of Interfaces.C.Pointers will say "with Interfaces.C.Strings" (or at least will act as if it did).
!appendix

!section B.3.2(00)
!subject Clarify the usage of exceptions in Interfaces.C.Pointers
!reference RM95 B.3.2
!from Pascal Leroy 96-04-29
!reference 96-5528.d Pascal Leroy 96-4-29>>
!discussion

The package Interfaces.C.Pointers contains various subprograms with parameters
of type Pointer.  For all these subprograms, an exception must be raised when
one of the Pointer parameters is null.  However, there seems to be some
hesitation as to which exception must be raised:

Value, Copy_Terminated_Array, Copy_Array and (maybe) Virtual_Length must raise
Interfaces.C.Strings.Dereference_Error.

"+", "-", Increment and Decrement must raise Pointer_Error.

While this semantics is well-defined (except perhaps for Virtual_Length), it
seems quite strange that two exceptions are involved for very similar
programming errors.  It seems also strange that Interfaces.C.Pointers raises
an exception which is declared in Interfaces.C.Strings.  What was the point of
declaring the exception Pointer_Error if it's not used everywhere?  What is
the intent?

****************************************************************

!section B.3(00)
!subject AI-00141 -- Exceptions in Interfaces.C and its Children
!reference B.3(00)
!reference 96-5665.a Pascal Leroy 96-8-30
!from Bob Duff
!reference 96-5671.a Robert A Duff 96-8-31>>
!discussion

> The declarations of exceptions Pointer_Error and Dereference_Error are moved
> from Interfaces.C.Pointers and Interfaces.C.Strings, respectively, to the
> visible part of Interfaces.C.

Everybody who was at the Montreux meeting knows my opinion, but I'll say
it here for the record.

I agree with the technical arguments set forth by Pascal Leroy in
AI95-00141/01.  If it were 1994, I would not hesitate to fix it in the
manner suggested by the AI draft.  However, it seems to me
insufficiently broken to fix at this point.  Furthermore, I suspect that
*very* few programs will run into the problems mentioned -- in 99.9% of
programs using these subprograms, the exceptions will not be handled.
These exceptions (like most exceptions) are primarily just run-time
checks for catching bugs.

> !priority High

I agree it's high priority, since if there is some chance we'll make
this language change, the sooner the better.  Let's decide for sure at
the next meeting.

> !difficulty Hard

Only because one Bob Duff is being conservative, when everybody else
agrees (at least everybody else at the Montreux meeting).  ;-)

>    3) It is likely that the body of Interfaces.C.Pointers will have to have a
>       with clause for package Interfaces.C.Strings, in order to raise the
>       exception Dereference_Error.  This has the potential of carrying a
>       penalty in object code size of linked programs, since the closure of a
>       program that uses Interfaces.C.Pointer will probably comprise
>       Interfaces.C.Strings, even if the client code never needs that package.

This may be true, although I can think of an alternative implementation
that does better: declare Dereference_Error in its own package
(System.Dereference_Error_Kludge, say).  Rename it in
Interfaces.C.Strings.  Then Interfaces.C.Pointers can raise it without
with-ing Interfaces.C.Strings.  I don't think this trick has any
user-visible consequences; it is therefore valid.  Of course, System
still gets sucked in to the program, but System is small (I think), and
is sucked into most programs anyway.

This is a minor point -- my main point is just that it doesn't seem
quite bad enough to fix.

- Bob

****************************************************************

Questions? Ask the ACAA Technical Agent