Reading "integer literals" 86-07-23 AI-00051/07 1 | !standard 14.03.07 (06) 86-07-23 AI-00051/07 | !class binding interpretation 83-10-30 | !status approved by WG9/AJPO 86-07-22 | !status approved by Director, AJPO 86-07-22 | !status approved by WG9/Ada Board 86-07-22 | !status approved by Ada Board 86-07-22 !status approved by WG9/ADA Board 85-02-26 !status board-approved 84-06-29 !status committee-approved 84-02-06 !status received 84-01-29 !references 83-00091, 83-00092, 83-00094, 83-00206, 83-00407, 83-00412, 83-00491 !topic Reading "integer literals" !summary 84-05-11 Integer GET reads according to the syntax of an optionally signed numeric literal that does not contain a point. It raises DATA_ERROR if the characters read do not form a legal integer literal. For example, if integer GET attempts to read 0.3, 0E-3, or 20#0#, reading stops before the decimal point for 0.3, after the 3 for 0E-3, and after the second # for 20#0#; DATA_ERROR is raised for 0E-3 since legal integer literals are not allowed to have exponents containing minus signs. DATA_ERROR is also raised for 20#0#, since 20 is not an allowed base value. !question 84-07-13 The Standard says GET "reads according to the syntax of an integer literal," and raises DATA_ERROR if the input sequence "does not have the required syntax." Does reading stop at the minus sign for 0E-3 or at the 3? If it stops at the 3, is DATA_ERROR raised? For 0.3, does reading stop at the 3 or at the point? !recommendation 84-05-08 If the character sequence being read by integer GET satisfies the syntax for numeric_literal (preceded by an optional sign) and has a point, reading stops just before the point. DATA_ERROR is raised if the characters read do not satisfy the syntax for numeric_literal. If a character sequence satisfies the syntax for a numeric literal without a point but the literal fails to satisfy other legality rules, then GET raises DATA_ERROR. !discussion 84-05-11 The Standard says: "[GET] reads according to the syntax of an integer literal (which may be a based literal)." [14.3.7(6)] "The exception DATA_ERROR is raised if the sequence input does not have the required syntax or if the value obtained is not of the subtype NUM." [14.3.7(8)] Reading "integer literals" 86-07-23 AI-00051/07 2 "an integer literal is a numeric literal without a point" [2.4(1)], and numeric_literal is defined by a context-free syntax rule [2.4(2)]. "An exponent for an integer literal must not have a minus sign" [2.4.1(4)]. "The base [of a based literal] must be at least two and at most sixteen" [2.4.2(1)]. Now consider the examples: 0.3 2#0.3# 0E-3 2#0#E-3 20#0# There are two issues raised by the current wording -- when does reading stop and when is DATA_ERROR raised? The question of when reading stops is answered by the definition in 2.4(1). This narrative definition specifies the syntactic form of integer literals, i.e., they have the form of numeric_literals without a point. Hence, when reading 0.3, reading stops when the point is encountered and GET returns the value zero; the next character to be read is '.'. The intent in 14.3.7(8) was to ensure that GET consider a sequence of characters to form an integer literal if and only if the same sequence would be allowed in an Ada program as an integer literal. The curent wording does not satisfy this intent because it requires only that the input sequence have the required "syntax". The intent was that DATA_ERROR should be raised if the characters read do not form a LEGAL integer literal. For example, 2#0#E-3 has the form of a based literal without a point, and so satisfies the syntactic requirements for an integer literal. It is not, however, a legal integer literal because of the minus sign in the exponent. The syntactic rule for integer literals requires that reading stop after the 3. The legality rules require that DATA_ERROR then be raised. Similarly, for 20#0#, reading stops after the second # but DATA_ERROR is raised because 20 is not in the allowed range of base values. When reading 2#0.3#, reading stops when the point is encountered, but since 2#0 is not a legal integer literal (it does not satisfy the syntax for decimal_literal or based_literal), DATA_ERROR is raised.