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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,794c64d1f9164710
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-02-21 10:28:00 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0900.news.uu.net!reader0901.news.uu.net!not-for-mail
Message-ID: <3C753C66.8020509@mail.com>
Date: Thu, 21 Feb 2002 13:28:54 -0500
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
 rv:0.9.8+) Gecko/20020213
X-Accept-Language: en-us
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: functions, packages & characters
References: <mailman.1014282062.23400.comp.lang.ada@ada.eu.org>
 <20020221130715.12738.00000034@mb-bg.aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Cache-Post-Path: master.nyc.kbcfp.com!unknown@mosquito.nyc.kbcfp.com
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1014316077 reader1.ash.ops.us.uu.net 7835 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:20225
Date: 2002-02-21T13:28:54-05:00
List-Id: <comp.lang.ada>

Unversed Angel wrote:
>  Line_Buffer : String (1 .. 1000);

It's the twenty-first century. Isn't it about time we
got rid of fixed-size input buffers? Thank goodness
for the GNU reimplementation of the UNIX utilities,
which have done away with maximum line sizes, but on
my Sun, I still can't vi in a 200 column xterm.

Unless you have very domain-specific information,
using a fixed-size input buffer is an invitation
to errors. You will never pick a large-enough size.
I once had to process a .newsrc file, which is plain
text, whose longest line was several hundred thousand
characters long. The most pernicious error in such a
case is for the program to silently truncate the line,
or to split it into multiple lines. Using unbounded
input buffers prevents this from happening.