Re: More Uniform Ada libraries (was: Proving Correctness)

["Samuel T. Harris" <u61783@gsde.hou.us.ray.com>]

brentcarnellis@hotmail.com wrote:
> 
> On Wed, 05 Sep 2001 00:01:17 GMT, "Jeff Creem" <jeff@thecreems.com>
> wrote:
> >
> >Hmm.. I have had my share of complaints over the years with Apex but not
> >doing Text_IO.Get_Line correctly was never one of them...There are probably
> >literally > 100 million lines of code of Ada compiled with Apex deployed in
> >the world so to
> >assume that it is that broken on a regular basis is.....odd..
> 
> Yes, once fixed it will be a regression test nightmare for Rational.
> For example, if you do the following, don't expect it to work over a
> remote pipe.
> 
> with Text_IO;
> procedure Hello_World is
>    Text : String(1..100);
>    Len : Integer;
> begin
>    loop
>       Text_IO.Get_Line(Text, Len);
>       Text_IO.Put_Line("[Hello World] " & Text(1..Len));
>    end loop;
> end;
> 
> $ rsh ilab-02 hello_world
> eat me
> where is the response?
> [Hello World] eat me
> what?
> [Hello World] where is the response?
> what?
> [Hello World] what?
> thanks
> [Hello World] what?
> you suck
> [Hello World] thanks
> bye
> [Hello World] you suck

Funny, my rather dated Apex 2.0.8D for SGI IRIX 5
works with no problems (and that Apex is, what, over
4 years old).

And my VADS 621.52 works as well (and that is a
pre-Rational true-blue Verdix compiler).

Anyway, you are confusing expections with required
LRM behavior. "Broken" is a word used when the compiler
does not do as it should and what it should do is defined
in the LRM. Many things about the LRM are implementation
defined and many things about the model of files defined
for Text_IO are incompatible with many aspects of the
real-world.

Consider the Honeywell Ada compiler for the DPS-6.
Because of the way the DPS-6 buffered terminal input
and output, a standard put("prompt "); get_line(response,last);
would wait for the input and then output the prompt and
the response. This was a conforming and certified implementation.
My expectations concerning reasonable behavior remained
unsatisfied because of the brain-dead operating system.

Now consider that the Text_IO model for files requires
an end_of_line followed by an end_of_page followed by
an end_of_file at the end of a file. Most UNIX text files
will only have the end_of_line. Because of this, most
UNIX files should produce something like end_error
and the function call end_of_file will never yield true.
This would be conforming behavior and the compiler
cannot said to be broken. It can be said that the compiler
does not meet my expectation and I would like an enhancement
to handle this exceptional, but common, situation.
Indeed every compiler I've every used takes some pains
to infer the end_of_page and end_of_file by using
some form of buffering.

Now consider what impact that buffering will have
on interactive streams such as standard_input,
especially through remote pipes. An implementation
of Text_IO which meets most of our expectations
will be rather complicated indeed since most of
the real-world "files" do not fit the definition
of a Text_IO file.

-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"