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-Thread: 103376,5afe598156615c8b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) Date: Thu, 07 Dec 2006 17:35:00 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1165513333.321151.74320@73g2000cwn.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1165530900 7064 192.74.137.71 (7 Dec 2006 22:35:00 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 7 Dec 2006 22:35:00 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:wq/en/rCXZhQoRQRrd1RUEABGpw= Xref: g2news2.google.com comp.lang.ada:7857 Date: 2006-12-07T17:35:00-05:00 List-Id: "Adam Beneschan" writes: > Steve wrote: >> "Maciej Sobczak" wrote in message >> news:el6jss$268$1@cernne03.cern.ch... >> [snip] >> > >> > Any thoughts? >> > >> You have run across what I consider to be a weakness in the standard Text_IO >> library, it is one of the few things I find really annoying about Ada, which >> I really like otherwise. >> >> In Ada you can't write a simple program to read and process lines in a text >> file that looks something like: >> >> while not End_Of_File( inFile ) loop >> Get_Line( inFile, Input_Buffer, Count ); >> Process_Line( Input_Buffer( 1 .. Count ) ); >> end loop; >> >> The problem is that Get_Line reads a line of text into a string buffer and >> returns the count of characters read. Another problem is that this encourages programmers to place arbitrary limitations on things (line length in this case -- there's no sensible way to choose the length of Input_Buffer). In Ada 2005, you can use the Get_Line function: Input_Buffer: constant String := Get_Line(inFile); which returns the line, however long it is. (Well, there's still an arbitrary limitation, if your disk can hold 100 gigabytes, but String can hold only 2**31-1 bytes. Oh well, at least that limitation is not quite so severe. ;-)) There are many problems with the design of Text_IO... > It's a mistake to think of a line terminator as a "character"; this is > probably a common mistake among those used to using C and Unix (or > Linux or other OS's ending in "x") (or Solaris), but it's not even > correct to say that a line terminator is a character on other OS's. On > Windows, it's two characters (CR-LF). VMS, as I recall, doesn't use > any character as a line terminator, but keeps information on where > lines start and how long they are in an index or somewhere. Ada is a > portable language that needs to be implementable on all these systems > and others, so therefore it left the definition of "line terminator" up ^^^^^^^^^ > to the implementation and did not tie us to the concept that there has > to be a "character" involved. I believe the above is historically correct, but I don't buy the "therefore" above. For portability, Ada requires the implementation to translate from whatever OS conventions to Ada's conventions. It could just as well have required translating to the Unix convention instead of translating the rather record-oriented style of Text_IO. The Unix convention has certain advantages. - Bob