Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!enea!sommar From: sommar@enea.UUCP (Erland Sommarskog) Newsgroups: comp.os.vms Subject: Re: Size limitations Message-ID: <2172@enea.UUCP> Date: Tue, 11-Aug-87 17:30:32 EDT Article-I.D.: enea.2172 Posted: Tue Aug 11 17:30:32 1987 Date-Received: Fri, 14-Aug-87 01:43:41 EDT References: <8708050333.AA09967@ucbvax.Berkeley.EDU> Reply-To: sommar@enea.UUCP(Erland Sommarskog) Followup-To: comp.os.vms Organization: ENEA DATA Svenska AB, Sweden Lines: 29 In a recent article "ERI::SMITH" writes: >Kernighan and Pike ("The Unix Programming Environment", p. 47) note that >"There are implementation limitations with most programs that expect text >as input. We tested a number of programs on a 30,000 byte text file >containing no newlines, and surprisingly few behaved properly, because >most programs make unadvertised assumptions about the maximum length of a >line of text." In UNIX, of course, which uses what I call the paper-tape >concept rather than the 80-column card concept, a 30,000-column line is >SUPPOSED to be acceptable. (I wonder whether any of their programs that >worked on 30,000 bytes would fail on 32,769? or 65,540?). Under VMS, >of course, lots would break on 81 characters, lots more at 133, and most >of the rest at 257... But that does mean that Unix doesn't impose limitation of what you can do? No. Yes, you can have lines that are million characters, no problem. But if you want to have a line-feed charcter in a text string, thus without the character having the meaning of new line? As far as I know, this is not possible. The conclusion is that no matter what you do, you may get into problems. Since you need *some* convention to indicate new lines, you must introduce *some* restriction. VMS restricts you in size, but permits you having LF:s in text string. Unix does the other way. Which you prefer is a matter of taste. (And by the way, VMS does know of stream-LF format too. Unix knows only of stream-LF.) -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP