Hi there,

I am in the middle of a heated debate with Richard Riehle on LinkedIn, where we cannot get to terms with regard to the exact semantics of X'Valid in the context of input operations performed by standard Get procedure.
In short, consider the following example:

with Ada.Text_IO;
with Ada.Integer_Text_IO;
procedure Is_Valid_Test is
X : Integer range 0..200;
begin
Ada.Text_IO.Put("Get an Integer: ");
Ada.Integer_Text_IO.Get(X);
if X'Valid then
Ada.Text_IO.Put_Line("The Input is Valid ");
else
Ada.Text_IO.Put_Line("The Input is not Valid ");
end if;
end Is_Valid_Test;

When the input is 500, what should be the behavior of this program?
There are two interpretations:

1. Get is an input operation and can create invalid representations (as stated in 13.9.2, p.7). Then, the X'Valid test that follows Get(X) can be used to safely recognize whether the value is in the range or not. The program should print the second string (from the else branch), but should not raise any exceptions for this input (500).

2. Get is not an input operation in the meaning referred to in 13.9.2/7, or is an input, but only for type Integer (and it cannot create invalid integer representations on typical computers anyway). The X variable is an actual parameter that has a subtype that is different from the formal parameter and is subject to conversions when the Get subprogram exits normally (6.4.1/17,17a). This conversion should raise Constraint_Error for this input (500).

I have checked the above program on several on-line compilers, all of them behave according to interpretation 2 above.
Richard claims to get behavior 1 on his compiler.

What is your take on this? Any language lawyers?

Regards,
Maciej Sobczak

On 2023-09-23 22:22, Maciej Sobczak wrote:
>
> I have checked the above program on several on-line compilers, all of them behave according to interpretation 2 above.
> Richard claims to get behavior 1 on his compiler.
>
> What is your take on this? Any language lawyers?

The important thing is the definition of Ada.Text_IO.Integer_IO.Get [ARM
A.10.8(7-10)]:

"... 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. ...

"Returns, in the parameter Item, the value of type Num that corresponds to the
sequence input.

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

So a call to Get can only return a valid value of type Num (Integer for your
case) or raise Data_Error.

If Get is reading "500" then that certainly represents a valid value of type
Integer, and Get should copy that back to the actual parameter.

If you are using Ada (a language with run-time checks), then a check should be
made that the value is in the range of the actual parameter's subtype, here
Integer range 0 .. 200. That should fail and Constraint_Error should be raised.

However, if you are not using Ada because that check has been suppressed, then
the actual parameter will be left with the invalid value 500 and
Constraint_Error will not be raised.

If I build your program with checks enabled, I get Constraint_Error. If I build
it with checks suppressed, I get the not-valid message (GNAT 12.3).

--
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32

I believe Jeffrey's analysis is correct.

Note that there are some special cases for validity that are intended to
make it easier to write code like that you have. But they only make sense
for base subtypes (and the type you have is not that). Moreover, they are
not foolproof -- exceution is not erroneous in these cases, but they still
are a bounded error, and it is always correct for a bounded error to be
detected and raise Program_Error.

This can happen in practice, too. For instance, for Janus/Ada, enumeration
types with specified representations operate internally on the position
numbers, and thus reading an enumeration variable will convert the
representation to a position number with a table lookup. If the lookup
fails, Program_Error is raised, and that happens before the value ever can
be assigned to a named variable (and thus before any possible test of
validity). I believe that we identified other similar cases back in the day.
Probably one of them is the signalling NaN. Some bit patterns for float
values represent signalling NaNs, which trap instantly if read. That's at
the hardware level on most processors, so the only hope is the handle the
resulting exception. It's too late by the time you get to 'Valid.

Moral: to make truly bulletproof code, you have to handle exceptions AND use
'Valid. You probably can skip the exceptions if everything is typed with
integer basetypes, but if any other kinds of types are involved, they are
necessary.

Randy.

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message
news:uenmg1$qctd$1@dont-email.me...
> On 2023-09-23 22:22, Maciej Sobczak wrote:
>>
>> I have checked the above program on several on-line compilers, all of
>> them behave according to interpretation 2 above.
>> Richard claims to get behavior 1 on his compiler.
>>
>> What is your take on this? Any language lawyers?
>
> The important thing is the definition of Ada.Text_IO.Integer_IO.Get [ARM
> A.10.8(7-10)]:
>
> "... 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. ...
>
> "Returns, in the parameter Item, the value of type Num that corresponds to
> the sequence input.
>
> "The exception Data_Error is propagated if the sequence of characters read
> does not form a legal integer literal or if the value obtained is not of
> the subtype Num."
>
> So a call to Get can only return a valid value of type Num (Integer for
> your case) or raise Data_Error.
>
> If Get is reading "500" then that certainly represents a valid value of
> type Integer, and Get should copy that back to the actual parameter.
>
> If you are using Ada (a language with run-time checks), then a check
> should be made that the value is in the range of the actual parameter's
> subtype, here Integer range 0 .. 200. That should fail and
> Constraint_Error should be raised.
>
> However, if you are not using Ada because that check has been suppressed,
> then the actual parameter will be left with the invalid value 500 and
> Constraint_Error will not be raised.
>
> If I build your program with checks enabled, I get Constraint_Error. If I
> build it with checks suppressed, I get the not-valid message (GNAT 12.3).
>
> --
> Jeff Carter
> "If you don't get the President of the United States on that
> phone, ... you're going to have to answer to the Coca-Cola
> Company."
> Dr. Strangelove
> 32
>

On 2023-09-26 9:13, Randy Brukardt wrote:

> ... for Janus/Ada, enumeration types with specified representations
> operate internally on the position numbers

Hm, that's interesting. Is that also the representation for record
components of such an enumerated type?

For example, if I have:

type Command is (Off, On) with Size => 4;
for Command use (Off => 2, On => 5);
type Two_Commands is record
C1, C2: Command;
end record
with Pack, Size => 8;

TwoC : Two_Commands := (C1 => On, C2 => Off);

will the record components (in memory) have the values C1 = 1 and C2 = 0
(position numbers) or C1 = 5, C2 = 2 (specified representation)?

If they are represented by position numbers in the record, many if not
most of my embedded Ada programs would fail if compiled with Janus/Ada,
because the record values stored in I/O control registers or accessed
via DMA would be wrong.

Damn, I thought those programs were not so compiler-dependent :-(

No, the specified representation is always used when storing to memory (with
the single exception of loop parameters, which cannot have address clauses
or other representation specifications). I think even enum parameters are
written in the representation. However, any time an enumeration value is
read into a register it is converted to a position number. Usually, such
values are used in indexing, comparing, or an attribute like 'Pos or 'Succ,
all of which are defined to work on position numbers. But if you simply
assign the value out again, it will get converted both ways. We do have an
optimization to remove pairs of TOREP/DEREP, but not the reverse since
Program_Error is a possibility from DEREP. (Well, unless unsafe
optimizations are on, but I don't recommend using those for the obvious
reasons.)

Randy.

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:knff56Fdjg6U1@mid.individual.net...
> On 2023-09-26 9:13, Randy Brukardt wrote:
>
>> ... for Janus/Ada, enumeration types with specified representations
>> operate internally on the position numbers
>
>
> Hm, that's interesting. Is that also the representation for record
> components of such an enumerated type?
>
> For example, if I have:
>
> type Command is (Off, On) with Size => 4;
> for Command use (Off => 2, On => 5);
> type Two_Commands is record
> C1, C2: Command;
> end record
> with Pack, Size => 8;
>
> TwoC : Two_Commands := (C1 => On, C2 => Off);
>
> will the record components (in memory) have the values C1 = 1 and C2 = 0
> (position numbers) or C1 = 5, C2 = 2 (specified representation)?
>
> If they are represented by position numbers in the record, many if not
> most of my embedded Ada programs would fail if compiled with Janus/Ada,
> because the record values stored in I/O control registers or accessed via
> DMA would be wrong.
>
> Damn, I thought those programs were not so compiler-dependent :-(
>