From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,be23df8e7e275d73 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-05 06:20:16 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!titan03.ksc.nasa.gov!niven.ksc.nasa.gov!usenet From: "Samuel T. Harris" Newsgroups: comp.lang.ada Subject: Re: More Uniform Ada libraries (was: Proving Correctness) Date: Wed, 05 Sep 2001 08:13:31 -0500 Organization: Raytheon Aerospace Engineering Services Message-ID: <3B9624FB.5CC661EB@gsde.hou.us.ray.com> References: <9kea9a$lsc$1@nh.pace.co.uk> <9keduf$qvc$1@a1-hrz.uni-duisburg.de> <9kelv1$riq$1@a1-hrz.uni-duisburg.de> <9krkfa$g12$1@nh.pace.co.uk> <3b9456ca.15085013@news.tc.umn.edu> <3b95a622.10966074@news.tc.umn.edu> Reply-To: samuel_t_harris@raytheon.com NNTP-Posting-Host: sstf-fw.jsc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 [en] (X11; U; IRIX64 6.2 IP19) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:12747 Date: 2001-09-05T08:13:31-05:00 List-Id: brentcarnellis@hotmail.com wrote: > > On Wed, 05 Sep 2001 00:01:17 GMT, "Jeff Creem" > 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!"