!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 via the parameter Width and the number of characters needed for the literal. Is this 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 via the parameter Width and the number of characters needed for the literal. Is this 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 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. ****************************************************************