Question about what reading from file according to AI22-0144-1 does in some corner cases

[CKWG]

I'm writing the C-test for AI22-0144-1.

This is the RM sytax excerpt for integer literals.

  Syntax of integer literal:
  2.4(1)       ...; an integer literal is a numeric_literal without a point.
  2.4(2)       numeric_literal ::= decimal_literal | based_literal
  2.4.1(2)     decimal_literal ::= numeral [exponent]   
  2.4.1(3)     numeral ::= digit {[underline] digit}
  2.4.1(4)     exponent ::= E [+] numeral | E – numeral
  2.4.1(4.1/2) digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  2.4.1(5)     An exponent for an integer literal shall not have a minus sign.
  2.4.1(5.a)   Ramification: Although this rule is in this subclause,
               it applies also to the next subclause.
  2.4.2(2)     based_literal ::= base # based_numeral # [exponent]
  2.4.2(3)     base ::= numeral
  2.4.2(4)     based_numeral ::= extended_digit {[underline] extended_digit}
  2.4.2(5)     extended_digit ::= digit | A | B | C | D | E | F
  A.10.8(8)    If the value of the parameter Width is zero, skips any leading
               blanks, line terminators, or page terminators, then reads a
               plus sign if present or (for a signed type only) a minus sign
               if present, then reads the longest possible sequence of
               characters matching the syntax of a numeric literal without
               a point, or a prefix of such syntax... (Text of AI22-0144-1)

Rule 2.4.1(2) and 2.4.2(2) have been adapted to integer literal according
to 2.4(1) by omitting the part with the dot. This is correct since reading
stops when a dot is encountered in the input string, leaving the dot in the
input string, for instance reading "1.0" stops after '1' and returns the
integer 1; it does not raise Data_Error.
2.4.2(6) is a legality rule which is applied after reading the literal has
ended. It talks about the base range 2 .. 16 and the maximum value of an
extended digit.

Problem 1

Now there is a problem with 2.4.1(4). The old Ada 83 CE3704F "legacy test"
has "10E-2X" as input stream and the reading stops before 'X'. Rule 2.4.1(5)
being a syntax rule (it's under the headline Syntax), not a legality rule,
reading must stop after the exponent 'E' before '-', leaving "-2X" in the
input stream.
Because test CE3704F is a legacy test, insisting on my interpretation of
the RM rules would mean that each and every still existing Ada compiler
would have to change if it wants to comply tho the ACVC.

I do not deem this a viable option. So I propose to insert a new headline
Legality Rules before 2.4.1(5) and 2.4.1(5.a).

With this change, the old interpretation leaving only 'X' in the input
stream when reading "10E-2X" is still correct.

Problem 2

Reading exactly Width=10 characters of "12#11B0# X", what is the result?
Data_Error because of trailing blanks or the integer value 12#11B0#?

  A.10.8(8)    ... If a nonzero value of Width is supplied, then exactly
               Width characters are input, or the characters (possibly
               none) up to a line terminator, whichever comes first; any
               skipped leading blanks are included in the count.

Attribute 'Value ignores leading and trailing blanks.
Reading from String returns the position of the last character read.
Reading with Width=0 stops upon blanks.

"12#11B0# X"  (note: 'X' at position 10) will raise Data_Error, the whole
              sequence will be evaluated and a blank inside is illegal.
"12#11B0#  X" (note: 'X' at position 11, not read) IMHO will also raise
              Data_Error. Contrary to the 'Value case, there is nowhere
              a statement that trailing blanks are ignored when reading
              from a file. They always stop reading.

There is no ACVC test for this case (at least, I didn't find one).
GNAT does not raise Data_Error.

Which interpretation is correct?

[sttaft]

Good questions!

I agree with your suggested resolution of Problem 1, namely to consider the rule about negative exponents as a legality rule.

For Problem 2, here are my comments:

Reading exactly Width=10 characters of "12#11B0# X", what is the result?
Data_Error because of trailing blanks or the integer value 12#11B0#?

A.10.8(8) ... If a nonzero value of Width is supplied, then exactly
Width characters are input, or the characters (possibly
none) up to a line terminator, whichever comes first; any
skipped leading blanks are included in the count.

Attribute 'Value ignores leading and trailing blanks.
Reading from String returns the position of the last character read.
Reading with Width=0 stops upon blanks.

A.10.8(10/3) says:

The exception Data_Error is propagated if the sequence of characters read does not form a legal integer literal or ...

This seems unambiguous that the "sequence of characters read" would include any trailing spaces. Perhaps the only ambiguity might be whether "123 " could be considered to "form" a legal integer literal, since the presence or absence of leading or trailing blanks is never mentioned in any syntax rule.

"12#11B0# X" (note: 'X' at position 10) will raise Data_Error, the whole
sequence will be evaluated and a blank inside is illegal.
"12#11B0# X" (note: 'X' at position 11, not read) IMHO will also raise
Data_Error. Contrary to the 'Value case, there is nowhere
a statement that trailing blanks are ignored when reading
from a file. They always stop reading.

There is no ACVC test for this case (at least, I didn't find one).
GNAT does not raise Data_Error.

Which interpretation is correct?

Given what GNAT is currently doing, I might consider adjusting the RM to match it, explicitly ignoring trailing blanks. If there is significant amount of code taking advantage of the current GNAT rules, it could be a bit of an earthquake for that code to suddenly start getting Data_Errors. The fact that leading and trailing blanks are ignored by 'Value seems an additional justification. If other compilers currently raise Data_Error, turning off that behavior would be less likely to impact existing "working" code.

[CKWG]

So I think an AI is direly needed.

Problem 1 thus will have a good solution. (The 83 RM did not make a clear distinction between syntax and legality rules. This might be the reason of the confusion.)

Problem 2: We should try to find out how other compilers treat problem 2. Both solutions have their merits. I myself tend to Data_Error for trailing blanks. The final decision will also affect reading enumerations.

Problem 3: There is another case.
A.10.8(8) ... or (for a signed type only) a minus sign if present...
This is clearly a syntax rule. Thus when reading a modular integer, " -123" must stop before the minus sign.
I have not yet checked what GNAT does. If it reads the whole thing and only then raises Data_Error, we have a problem. There is no simple way to reformulate A.10.8(8) as a legality rule.

[sttaft]

So I think an AI is direly needed.

Agreed. Feel free to start one.

Problem 1 thus will have a good solution. (The 83 RM did not make a clear distinction between syntax and legality rules. This might be the reason of the confusion.)

Good point, and this ACATS test might predate the explicit Ada 95 split. When doing the Ada 95 manual, I am quite sure we didn't actually run this ACATS test to verify its interpretation of this split.

Problem 2: We should try to find out how other compilers treat problem 2. Both solutions have their merits. I myself tend to Data_Error for trailing blanks. The final decision will also affect reading enumerations.

Randy Brukardt has done these tests in the past, since he at least used to have various different compilers available.

Problem 3: There is another case. A.10.8(8) ... or (for a signed type only) a minus sign if present... This is clearly a syntax rule. Thus when reading a modular integer, " -123" must stop before the minus sign. I have not yet checked what GNAT does. If it reads the whole thing and only then raises Data_Error, we have a problem. There is no simple way to reformulate A.10.8(8) as a legality rule.

It sounds like we don't know whether this is a problem. Do you have time to test GNAT?

-Tuck

[CKWG]

So I think an AI is direly needed.

Agreed. Feel free to start one.

I will as soon as this discussion has a definite answer to all three problems.
Is there any chance that this will get in the Ada 22 TC or is it too late?

Good point, and this ACATS test might predate the explicit Ada 95 split. When doing the Ada 95 manual, I am quite sure we didn't actually run this ACATS test to verify its interpretation of this split.

This legacy has has not been touched since 1987.

Problem 2: We should try to find out how other compilers treat problem 2. Both solutions have their merits. I myself tend to Data_Error for trailing blanks. The final decision will also affect reading enumerations.

Thinking further, there is nothing in the syntax that says that trailing blanks are acceptable, they simply stop reading.

Randy Brukardt has done these tests in the past, since he at least used to have various different compilers available.

It sounds like we don't know whether this is a problem. Do you have time to test GNAT?

Not in the next days I fear, you know, retirees never have time.

[ARG-Editor]

Problem 2: We should try to find out how other compilers treat problem 2. Both solutions have their merits. I myself tend to Data_Error for trailing blanks. The final decision will also affect reading enumerations.

I agree. Not raising Data_Error is relatively easy to describe, but it might be a pain to implement depending on how processing is done for these routines. If the checking is written purely front-to-back, figuring out what to do when hitting a blank requires lookahead. Some restructuring of the code would be necessary. It seems wrong to penalize implementers that actually read the RM!

Randy Brukardt has done these tests in the past, since he at least used to have various different compilers available.

Yes, but of course that requires someone writing a test. That's not likely to be me in this case. Also, my ObjectAda key has expired. (It didn't work the last time I tried to test something on it.) I haven't tried to renew it as I haven't recently worked on ACATS tests. Perhaps in a month or so. (My GNAT is old these days as well, since AdaCore withdrew support for the ACATS. I never actually asked about that, as it seemed obvious what the answer would be...)

Problem 3: There is another case. A.10.8(8) ... or (for a signed type only) a minus sign if present... This is clearly a syntax rule. Thus when reading a modular integer, " -123" must stop before the minus sign. I have not yet checked what GNAT does. If it reads the whole thing and only then raises Data_Error, we have a problem. There is no simple way to reformulate

A.10.8(8)

as a legality rule. It sounds like we don't know whether this is a problem. Do you have time to

test GNAT? We need to test other compilers for this as well. Another thing we need a test for. The only reason we don't need to test problem 1 is that it is in the ACATS (from the Ada 83 ACVC, no less), so we're pretty sure everyone follows it.

[Lucretia]

procedure T is
   A : Integer := 10E-2X;
   B : Integer := 12#11B0# X;
begin
   null;
end T;

$ gnatmake t.adb 
gcc -c t.adb
t.adb:2:22: error: negative exponent not allowed for integer literal
t.adb:3:27: error: binary operator expected
gnatmake: "t.adb" compilation error

[CKWG]

It sounds like we don't know whether this is a problem. Do you have time to
test GNAT?

-123 is completely read, then Data_Error is raised. Thus it's treated as a legality, not a syntax rule. But legality rules have to follow syntax rules, they cannot precede them.

Randy: I'll send you a first draft of the C-test.

[CKWG]

The new AI is in the New AIs folder, Title: AI22-0000-1 Syntax rules disagree with Text_IO.Get results.

[sttaft]

The new AI is in the New AIs folder, Title: AI22-0000-1 Syntax rules disagree with Text_IO.Get results.

Thanks!

[ARG-Editor]

The AI has been assigned number AI22-0151-1, and will be on the agenda for the next ARG meeting.

[ARG-Editor]

Christoph wrote a proposed ACATS test for the integer part of this question, and I asked my various vendor contacts to run it and provide the results. I've put those results into the AI; we should use those to inform our choices for fixing these issues.

[ARG-Editor]

AI22-0151-1 was approved at ARG Meeting #63N, so this issue is concluded and is now closed.