Version 1.1 of acs/ac-00042.txt

Unformatted version of acs/ac-00042.txt version 1.1
Other versions for file acs/ac-00042.txt

!standard G.1.3(11-19)          02-07-11 AC95-00042/01
!class confirmation 02-07-11
!status received no action 02-07-11
!subject Exception raised by Complex_IO.Get

!topic Exception raised by Complex_IO.Get
!reference RM95-G.1.3(11-19)
!from Adam Beneschan 06-28-02

In the sections on Text_IO for integer and real types, RM95 specifies
that for the Get routine, the "longest possible sequence of characters
matching" the specified syntax is read.  (See A.10.8(8), A.10.9(13).)
This rule gives a precise definition of where the file position should
be in the event that the file contains a badly formed number and
Data_Error is raised.

No such rule is present in G.1.3.  Is a similar rule supposed to
apply, or is the resulting file position implementation-defined?


From: Pascal Leroy
Sent: Friday, July 12, 2002  2:01 AM

Well, the problem is that the sentence in A.10.8(8) (the longest possible
sequence of characters, etc) is not to be taken at face value.  Robert has
explained many times that no actual Ada implementation works that way,
because otherwise you couldn't validate (and moreover it would be hard to
implement because you would need to do an arbitrary long lookahead).  The
ACATS, not the RM, is what defines the rules in this area.  This may be
unfortunate from a formal standpoint, but fixing the RM would be hard and
not very useful anyway.

So I don't see why we would bother to improve the wording for Complex_IO
when the wording for Text_IO is already cheesy.  The resulting file position
for Complex_IO is perfectly well defined by the ACATS tests that check the
behavior of Complex_IO.


From: Robert Dewar
Sent: Friday, July 12, 2002  4:14 AM

I agree, and I also agree it is not worth trying to fix the cheesy wording
in Text_IO :-)


Questions? Ask the ACAA Technical Agent