Version 1.3 of ais/ai-00253.txt
!standard C.3.1 (08) 01-05-20 AI95-00253/02
!class binding interpretation 00-12-06
!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.
!question
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.
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