Version 1.5 of ais/ai-00253.txt

Unformatted version of ais/ai-00253.txt version 1.5
Other versions for file ais/ai-00253.txt

!standard C.3.1 (08)          01-09-07 AI95-00253/03
!class binding interpretation 00-12-06
!status WG9 approved 01-10-05
!status ARG approved 8-0-0 01-05-20
!status work item 00-12-06
!status received 00-12-06
!qualifier Error
!priority Low
!difficulty Easy
!subject The legality rules for pragmas Attach_Handler and Interrupt_Handler are similar
!summary
Pragma Interrupt_Handler is only permitted to name a subprogram declared in the protected definition where it appears. Pragma Interrupt_Handler is allowed in a single_protected_definition. These restrictions are similar to the restrictions on pragma Attach_Handler.
!question
Why is it that pragma Attach_Handler can only appear in the protected definition where the named subprogram is declared (see C.3.1(7)) but there's no such restriction for pragma Interrupt_Handler (see C.3.1(8))?
In fact, pragma Interrupt_Handler is permitted to name a protected procedure that's declared far away, in some other compilation unit, if it so desires. Indeed, it can even name a protected procedure in an object; but one cannot do so for pragma Attach_Handler. Why the difference? Was this an oversight in the wording of the standard or was it intentional?
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
This was an oversight in the wording of the standard; the rules for the two pragmas were intended to be the same with the single exception that objects of a protected type containing pragma Interrupt_Handler must be declared at library level, while there is no such restrictions for objects of a type containing pragma Attach_Handler.
!corrigendum C.03.01(08)
Replace the paragraph:
The Interrupt_Handler pragma is only allowed immediately within a @fa{protected_definition}. The corresponding @fa{protected_type_declaration} shall be a library level declaration. In addition, any @fa{object_declaration} of such a type shall be a library level declaration.
by:
The Interrupt_Handler pragma is only allowed immediately within a @fa{protected_definition} where the corresponding subprogram is declared. The corresponding @fa{protected_type_declaration} or @fa{single_protected_declaration} shall be a library level declaration. In addition, any @fa{object_declaration} of such a type shall be a library level declaration.
!ACATS test
Add test cases to BXC3002 to check that both pragmas Attach_Handler and Interrupt_Handler are allowed in a single_protected_object, and to check that the parameterless procedure is declared in the same protected object as the pragma.
!appendix

From: Ivan B. Cvar
Sent: Thursday, November 30, 2000 12:04 PM


!topic pragma INTERRUPT_HANDLER rules too permissive
!reference RM95-C.3.1(8)
!from Ivan B. Cvar 00-11-30
!keywords pragma INTERRUPT_HANDLER ATTACH_HANDLER
!discussion

This RM95 bug was not fixed by the Technical Corrigendum 1 nor AI95-00121.
I've attached the related email correspondence, below.

...Ivan



From: Tucker Taft
Subject: Re: pragma interrupt_handler
Date: Wed, 24 Sep 1997 23:01:35 -0400

> Hi y'all.   Here's a seemingly innocent question for you...

Yeah, sure...

> Regarding: C.3.1 Protected Procedure Handlers
>
> Why is it that pragma ATTACH_HANDLER can only appear in the protected
> definition where the named subprogram is declared (see SNA C.3.1(7)) but
> there's no such restriction for pragma INTERRUPT_HANDLER (see C.3.1(8))
>
> In fact, pragma INTERRUPT_HANDLER is permitted to name a protected procedure
> that's declared far away, in some other compilation unit, if it so desires.
> It can also refer to a protected procedure denoted by PROT_OBJ.PROC,
> or ACCESS_TO_PROT_SUBP.all, but one cannot do so for pragma ATTACH_HANDLER.
> Why the difference?   Was this an oversight in the wording of the RM95
> or was it intentional?

There was not supposed to be any difference.  This is apparently just an
oversight in the wording for Interrupt_Handler.  The intent was that
it can only apply to protected procedures declared immediately within
the same protected definition.  Also, presumably there is no reason why
Interrupt_Handler shouldn't be allowed inside a single_protected_declaration.

RM bug!

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

Questions? Ask the ACAA Technical Agent