Version 1.4 of ai05s/ai05-0036-1.txt

Unformatted version of ai05s/ai05-0036-1.txt version 1.4
Other versions for file ai05s/ai05-0036-1.txt

!standard A.10.6(8)          07-01-18 AI05-0036-1/01
!standard A.10.10(11)
!class confirmation 07-01-18
!status WG9 Approved 08-06-20
!status ARG Approved 7-0-2 06-11-09
!status work item 07-01-18
!status received 07-01-09
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Number of characters to be output for Text_IO for enumerations
!summary
The number of characters to be output for an enumeration literal is as defined in A.10.10(10,11).
!question
A.10.10(10,11) specify the <number of characters to be output> via the parameter Width and the number of characters needed for the literal. Is this <number of characters to be output> identical with the "number of characters to be output" in A.10.6(8)? (Yes.)
My compiler vendor disagrees.
!response
A.10.6(8) clearly states that it applies to Put for enumeration types. A.10.10(11) is the only place where the characters to be output are defined, so if it does not define the "number of characters to be output" there would be no definition at all. It's unfortunate that the third sentence of A.10.10(11) uses "characters produced" rather than "characters to output" (as does the corresponding wording for integers in A.10.8(13)), but no other interpretation makes sense (outputting more characters than will fit surely should raise Layout_Error). Thus, we conclude that the language is clear.
!ACATS Test
CE3906E.ADA tests these rules, but unfortunately, it does not try a Width parameter. CE3706F.ADA makes similar tests with Width parameters for integer types; but it too does not try a value that would fit if the Width parameter was ignored.
Test CXAA0Z1.A was submitted to test this interpretation.
!appendix

!topic What is the "number of characters to be output"?
!reference Ada 2005 RM A.10.6(8), A.10.10(10,11)
!from Christoph Grein 07-01-09
!discussion
(This RM wording has been present forever.)

A.10.10(10,11) specify the <number of characters to be output> via
the parameter Width and the number of characters needed for the literal.
Is this <number of characters to be output> identical with the "number
of characters to be output" in A.10.6(8)?

See the program at end for explanation.

My expected result is (b denoting the blank character)
  12345678901234567890
  bbbbbbbbbb
  LITERALbbbb
  <Layout_Error>
because 11 characters have to be output, which do not fit on the rest of
the line, so a new line must be inserted before the value.
Then 21 characters have to be output, which do not fit on the bounded
line, so Layout_Error has to be raised.

Gnat's unexpected result is
  12345678901234567890
  bbbbbbbbbbLITERALbbb
  bLITERALbbbbbbbbbbbb
  bb
and AdaCore claim their interpretation is correct (and more logical than
mine).
-----------------------------------------------
with Ada.Text_IO;
use  Ada.Text_IO;

procedure Test_Enum_IO is

  type Enum is (Literal);
  package Enum_IO is new Enumeration_IO (Enum);
  use Enum_IO;

begin

  Set_Line_Length (20);

  Put_Line ("12345678901234567890");
  Set_Col (11);
  Put (Literal, Width => 11);
  Put (Literal, Width => 21);

end Test_Enum_IO;

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

From: Jean-Pierre Rosen
Sent: Tuesday, January 9, 2007  3:36 AM

I would support Christoph's interpretation here, because that's what 
would happen with numbers. The fact that blanks are output before a 
number, but after a literal, should not change the behaviour.

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

From: Pascal Leroy
Sent: Tuesday, January 9, 2007  3:44 AM

I agree with your interpretation.  I think that A.10.6(8) is perfectly
clear (whether it is "useful" or "logical" is a different issue) and I see
no reason to believe that the number of characters discussed in this
paragraph is different from the number of characters given by the Width
parameter.  If the two numbers are different, what is A.10.6(8) talking
about anyway?

I find it particularly silly that Layout_Error is not raised in the second
case, and that GNAT is "spilling" white space on the next line.  Writing a
21-character field on a 20-character line has to be an error, and should
definitely be signaled by an exception.

Incidentally IBM Apex does produce exactly the output that you expect.

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

From: Christoph Grein
Sent: Tuesday, January 9, 2007  3:59 AM

So if it should be decided that Gnat is definitely wrong, would an ACATS
test be needed to force this interpretation? [This is how I interpret
the reply of AdaCore to my bug report.]

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

From: Pascal Leroy
Sent: Tuesday, January 9, 2007  6:49 AM

Robert Dewar likes to point out that there are quite a few places already
where the semantics of the I/O are nailed down by the ACATS, not by the
RM.  Although I believe that in the case you mention the RM is
unambiguous, his viewpoint would argue in favor of adding an ACATS test to
check for this case.

However, given that only limited resources are available, it can be argued
that it is more important to devote energy to writing ACATS tests for the
new Ada 05 features than for obscure I/O issues.

I guess I am saying that constructive discussion with your vendor is
probably a preferable route than going through some official channel,
especially if you want to see a resolution before you retire.  On the
other hand, you are certainly welcome to formally ask the ARG for a
resolution, or to submit a candidate ACATS test to the ACAA.

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


Questions? Ask the ACAA Technical Agent