Version 1.1 of acs/ac-00057.txt

Unformatted version of acs/ac-00057.txt version 1.1
Other versions for file acs/ac-00057.txt

!standard 2.8(13)          03-07-22 AC95-00057/01
!class binding interpretation 03-07-22
!status received no action 03-07-22
!status received 03-02-26
!subject Warnings for unrecognized pragmas should be advice, not a requirement
!summary
!appendix

!topic Warnings for unrecognized pragmas should be advice, not a requirement
!reference RM95-2.8(13)
!from Gary Dismukes 2003-02-26 4:17 PM

It seems that the Implementation Requirement in 2.8(13):

  13   The implementation shall give a warning message for an unrecognized
  pragma name.

should really be moved to Implementation Advice, as there's no semantic force
to this and not any specification of a what a warning message is (it could just
be an empty string).

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

From: Robert A. Duff
Sent: Wednesday, February 26, 2003  4:58 PM

Did Robert put you up to this?  And was he wearing his "pedantic" hat at
the time?  ;-)

I have a pedantic hat, too, but I wear my "practical" hat in this case.

Anyway, I do not agree that this should be IA, nor that it has "no
semantic force".  It is exactly analogous to 1.1.3(4), which requires
implementations to "identify" programs that contain illegal stuff.  It
does not define precisely what it means to "identify".  It's a matter
for validation authorities to determine whether errors have been
correctly "identified".  If your identification is to print out an empty
string for errors, but print nothing for non-errors, then you will (and
should) fail validation.

1.1.3(4) is perhaps the single most important rule in the entire Ada
language.  Many languages do not have such a rule!  I hope this rule is
not meaningless.

The pragma-warnings issue is similar.  You can claim anything you like
constitutes "giving a warning message", but if you make ridiculous
claims, you should fail validation.

I can't formally define "warning message", nor what it means to "give"
one.  Nonetheless, I know one when I see one.  I hope validation
authorities do, too.

In other words, this requirement is testable (and just like all the
other B tests, it requires a wee bit of judgement to see if you pass).

Finally, let's look at the cost/benefit ratio: The cost of this proposed
change is near zero.  The benefit is exactly zero.  No compiler writers
or users will take any action in response to such a change.  So I say,
let's leave it moot (i.e. !no action on the AI).  Robert will like my
use of "moot" here.  ;-)

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

From: Robert I. Eachus
Sent: Wednesday, February 26, 2003  5:34 PM

Other people can be pedantic without instigation by Robert Dewar. ;-)

Otherwise, I agree completely.  This is a testable requirement, and it
should be a requirement.

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

From: Randy Brukardt
Sent: Wednesday, February 26, 2003  5:44 PM

Sure, but can anyone not named "Robert" be pednatic? :-) :-)

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

From: Gary Dismukes
Sent: Thursday, February 27, 2003  12:31 AM

> Did Robert put you up to this?  And was he wearing his "pedantic" hat at
> the time?  ;-)

Yes, good guess, Robert did suggest posting this proposed change. :-)

> Finally, let's look at the cost/benefit ratio: The cost of this proposed
> change is near zero.  The benefit is exactly zero.  No compiler writers
> or users will take any action in response to such a change.  So I say,
> let's leave it moot (i.e. !no action on the AI).  Robert will like my
> use of "moot" here.  ;-)

No argument about that.

I'm inclined to agree with Robert that this should be advice rather than
a requirement, but it doesn't seem like an issue worth any further discussion,
and it's fine with me to leave it as no action.

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

From: Pascal Leroy
Sent: Thursday, February 27, 2003  7:04 AM

> It seems that the Implementation Requirement in 2.8(13):
>
>   13   The implementation shall give a warning message for an unrecognized
>   pragma name.
>
> should really be moved to Implementation Advice, as there's no semantic force
> to this and not any specification of a what a warning message is (it could
> just be an empty string).

Do we really want to waste, er, spend precious ARG time answering questions
like that?  The ARG is capable of discussing the meaning of "warning" for
hours, and no user will ever see a difference, because even if the RM changes
no implementation will change.

Let that sleeping dog lie...

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

From: Craig Carey
Sent: Thursday, February 27, 2003  12:30 PM

There is possibly a significant background topic with warnings.

Suppose a programmer had a purpose of removing warnings about pragmas.
To achieve that, this could be tried:

    (1) A "pragma Warning" is added, unless it is "pragma Warnings" or
        whatever.

        The rule seems to require a warning appear at the first use of
        a pragma stopping warnings about pragmas.

    (2) If there was a new pragma that had a function of stopping warnings
        about pragmas, then that would be warned about.

        Such a pragma would allow this to be left unchanged instead of
        being altered to the second form:
            pragma Unreferenced (....);
            pragma Suppress (Elaboration_Check, On => ...);

So the purpose is contradicted.

GNAT does not produce a warning for its pragma suppressing warnings.
That is a sample implementation.
So using 2.8(13), it must have been recognized, even though missing
from the manual, or else the compiler is not passing the test of
2.8(13).

So then, the meaning of the idea/word "unrecognized" can be taken
from the compiler or its documentation.

If a compiler does not implement two different pragmas that are
present in GNAT (say), but it prints a warning for only one of them,
then it is passing the requirement of 2.8(13).

There are 2 cases:
(1) the case of the pragma it did produce a warning for:
   The rule says nothing in this case.

(2) the case of the pragma that it did not produce a warning for:
   An idea in (13a) maybe applies: it is a special mode:

   --------------------------------------------------------------------
    2.8(13.a)
        Ramification: An implementation is also allowed to have modes
        in which a warning message is suppressed, or in which the
        presence of an unrecognized pragma is a compile-time error.
   --------------------------------------------------------------------

   Special handling of the not-implemented pragma would be in the
   circumstance that the not-implemented pragma was recognized.
   So the condition that the pragma be "an unrecogized pragma name" is
   not satisfied.
   Thus in this case, my argument is that there is no requirement for
   a warning message.


At 03\02\27 14:03 +0100 Thursday, Pascal Leroy wrote:
>Do we really want to waste, er, spend precious ARG time answering questions
>like that? ...

Is there an objection to having an AI consider the whole topic of warning
messages. From the start it could be advancing slowly. It could cover the
topic of incompatibilities between vendors implementations. I don't seem
to see messages from Greenhills at this list. Greenhills extensions might
something that other compilers are invited to warn about.

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

Questions? Ask the ACAA Technical Agent