Schwarz, Konrad <konrad.schwarz@siemens.com> wrote, on 13 Nov 2009:
>
> > The same applies to LINE_MAX. The original intention of LINE_MAX
> > (which came in from POSIX.2) was to allow applications to find out
> > what length of line it is safe for them to _write_ for use as input
> > to standard utilities. In the fgets() example it is being used in
> > the opposite situation of an application reading lines.
>
> So it is perfectly legitimate for a conforming application to read
> lines into a statically allocated buffer of size LINE_MAX (or of
> any other size, for that matter). This contradicts Note 277 of
> http://austingroupbugs.net/view.php?id=177.
Since you said "statically allocated" you must be referring to
the LINE_MAX macro in <limits.h>. In that case the answer is yes,
provided LINE_MAX is not too large for such an allocation to be
possible, and provided the application either knows for sure
that no line of input will be longer than the LINE_MAX macro or
handles such lines appropriately.
Note 277 was written based on the assumption that the code was
trying to show how to handle lines from an arbitrary text file,
without dealing with partial lines. Not all applications need to
do that.
> Such a (conforming) application is also a counter example to the description
>in http://austingroupbugs.net/view.php?id=182, which says:
>
> I believe that it is safe to assume that applications using fgets()
> already assume that any stream being read with fgets() is connected
> to a text file. If the application does not have reason to believe
> that the input is from a text file, it should be using functions
> like read() or fread() rather than functions like fgets() and
> getline().
>
> e.g., because the application documents the maximum line length it handles.
>
> In that bug's Desired Action Section, by changing the wording to allow
> for having no limit on maximum line lengths, utilities such as grep
> need to handle unlimited line lengths.
You have that backwards. The grep utility is part of the implementation.
The maximum line length that grep (and other utilities) accept is what
determines the implementation's LINE_MAX value, not the other way round.
> I would expect this to be quite
> challenging to implement. Also, I would expect this change to cause
> many applications to stop being able to read text files. E.g., the
> revised fgets() example cannot, being limited to lines of length 16384
> at most.
No, the revised fgets() example has a comment indicating that
lines longer than 16384 can be handled piecemeal if desired:
// Verify that a full line has been read...
// If not report an error or prepare to treat the
// next time through the loop as a read of a
// continuation of the current line.
> The vendor of a POSIX system has the liberty of deciding not to
> support infinite line lengths. The writer of an POSIX conforming
> application does not (the application has to run on wierdnix
> systems to). Thus, this change places an undue and unfair burden on
> applications that wish to read text files.
When an application needs to be able to read from arbitrary text
files, the application writer has to decide whether to make the
application's maximum line length the same as that of the
implementation's utilities (by using {LINE_MAX} in some way), or
whether to impose a different limit (or no limit at all). That
decision does not affect whether or not the application conforms
to the standard. If the application has a smaller limit, the
application's documentation can simply state that input files must
not have lines longer than that limit.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|