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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1b1a6e7f6b4388de X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-17 09:40:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!npeer.de.kpn-eurorings.net!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Ada.Streams.Stream_IO.File_Type Date: Thu, 17 Jul 2003 17:42:10 +0100 Message-ID: References: NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) X-Trace: news.uni-berlin.de 1058460028 11850961 82.43.33.75 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:40412 Date: 2003-07-17T17:42:10+01:00 List-Id: "Craig Carey" wrote in message news:mt7chvs7heoihdv7a3a6psh5h8v1b46i2i@4ax.com... > On Tue, 15 Jul 2003 13:30:33 -0500, "David C. Hoos" > > The package Ada.TextIO.Text_Streams allows one > > to obtain the stream object corresponding to the > > standard input -- i.e.: > > > > Standard_Input_Stream : > > Ada.Text_IO.Text_Streams.Stream_Access := > > Ada.Text_IO.Text_Streams.Stream > > (Ada.Text_IO.Standard_Input); > > This comment is not on Text_Streams: > ... > A fix would be to add this next line to Ada.Streams.Stream_IO: > > function Standard_Input return File_Type; > > Anyone know why it is not in there already? Yes! Because you can use the technique given by David Hoos. > Portable Ada programs handling piping or CGI I/O may > need that unless using C (etc.). If an Ada program which is a client of the Common Gateway Interface (CGI) -- used by various web (HTTP) server programs to allow 'client' programs to dyamically generate web pages -- implements the interface by directly interacting with its 'standard input' and 'standard output' (in the Unix sense), it must be considered essentially non-portable. Such a program may be portable among Unix-based (maybe POSIX-based) environments, but generally not otherwise. In this case, the Ada program might just as well import the appropriate C functions to read or write bytes directly; I would suggest that in most cases interaction is all text-based anyway, and it would be easier and better to use Ada.Text_IO (and if the Ada implementation isn't able to handle line termination correctly, I would say that's a major problem with the implementation). For true portability, an Ada program which is intended to be used as a CGI client should put everything specific to interfacing with the environment into a package (named 'CGI' perhaps ;-) and I'm fairly sure at least one such package is available. To port the program to a (significantly different) environment, this package (only) needs to be reimplemented. This would provide further advantageous isolation (such as from changes to the HTTP header that a CGI client program should output). > ... > Currently GNAT 3.15's Text_IO.Text_Streams feature > stops reading, on encountering a ASCII.SUB character > (= character 10#26#). That's just a problem with GNAT, isn't it? > Presumably they don't like the RM's design. Presumably it's a simple bug in GNAT 3.15. It's quite reasonable (in my 'humble' opinion :-) for text-oriented I/O (except Look_Ahead and Get_Immediate) to stop on a SUB, but not stream-oriented I/O. The RM permits this; I think it would often be handy for Ada implementations to provide options with regard to line, page, and file termination. -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]