At Sun, 6 Dec 2009 21:09:40 +0100, Rhialto <rhialto%falu.nl@localhost> wrote:
Subject: Re: Weirdness in comm(1)
>
> On Sat 28 Nov 2009 at 20:29:23 -0500, Greg A. Woods wrote:
> > At Sun, 29 Nov 2009 01:42:08 +0700, Robert Elz
> > <kre%munnari.OZ.AU@localhost> wrote:
> > Subject: Re: Weirdness in comm(1)
> > >
> > > Personally, I think that all text processing applications (ones intended
> > > to process text files) should be defined to have undefined behaviour when
> > > given a non-text file as input (including not being composed of a number
> > > of
> > > lines (including 0) each of which ends in a \n.
> >
> > I think it may be easier and safer all around to always think of
> > newlines as separators rather than as _necessary_ terminators in unix
> > text files.
>
> No. Newlines are required at the end of each line.
>
> Quote from K&R, 2nd edition, page 151, par 7.1, "Standard Input and
> Output":
>
> A text stream consists of a sequence of lines; each line ends with a
> newline character.
>
> and next, to reinforce this:
>
> If the system doesn't operate that way, the library does whatever is
> necessary to make it appear as if it does.
I think you're confusing what it means to be "required" here.
Indeed, what I am actually suggesting that the library be fixed to do
whatever is necessary to make it appear as if a text file ending without
a newline actually does end with a newline, but to do so without
actually changing the file and also without inserting a phantom newline
at the end of the text stream.
The fgetln(3) function does meet the definitions you quote from K&R
quite well, assuming the calling code also pays careful heed to the
warning note given both in the description, and in the CAVEATS section
of its manual page.
Even the fgets() function does essentially what I say, though its
description is so damn terse that it may not be obvious that this is so.
My comment is intended first and foremost for human programmers,
especially those, such as myself, who are often more pedantic than well
written code should be. :-)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpEYkjFHIg9E.pgp
Description: PGP signature