James Kuyper Jr. ha escrit:
>
> That was the particular part that governs the conversions mentioned
> above. However, there are several other places where the standard treats
> '\n' specially:
>
> 7.19.3 p3 defines line-buffered files
> 7.19.7.2 p2 describes how new-line affects fgets()
> 7.19.7.7 p2 describes how new-line affects gets()
> 7.19.7.10 p2 requires puts() to append a new-line
> 7.19.10.4 p2 requires perror() to follow the message string with a
> new-line.
> 7.24.3.2 describes how new-line affects fgetws()
>
> Oddly enough, 7.19.7.4 p2 does not make a similar statement about
> fputs(). Was this an oversight? Should I file a defect report?

No, it is historical heritage (puts write a \n, fputs don't).
This is the way it was in Unix V7, and I believe it was that way earlier.
<http://www.freebsd.org/cgi/man.cgi?query=puts&manpath=Unix+Seventh+Edition>

For the reason, perhaps Dennis Ritchie might comment on.


Antoine
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37EB7672.A539D345@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> writes
>7.19.7.10 p2 requires puts() to append a new-line
>
>Oddly enough, 7.19.7.4 p2 does not make a similar statement about
>fputs(). Was this an oversight? Should I file a defect report?

I don't see why. I've always understood that definition to mean:

    int puts (const char *s) { fputs (s, stdout); fputc ('\n', stdout); }

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I've changed the subject line, partly because there's been a real swing
in the subject, but also because I've found a possible defect that I
want someone officially connected to comment on. I suspect that many
such people are currently filtering out the "Why's of C++ - Part
3(string discussion)" thread.

Pete Becker wrote:
>
> "Paul D. DeRocco" wrote:
....
> > Your description of the sort of translation that the library might make
> > applies to \n, but that's a special case. The standard mechanism for
> > passing text from one program to another (e.g., Unix pipes used to
> > implement text-based filters) _requires_ the ability to move to the start
> > of the next line, and there are at least two common standards for doing
> > this (\n and \r\n). If the inventors of C didn't pick one, and make the

The C standard didn't pick one. However, it was written to allow (a
possibly different) one to be picked by each implementor. They also
wrote it to allow for other methods of handling lines, that are used on
other operating systems, such as fixed-length lines with no delimiters.
On such systems, the '\n' you see in C is not actually present in the
file. It's inserted/deleted by the standard library I/O function when
they read/write lines from/to such files.

> > library deal with systems that disagree, then virtually every text-based
> > program would need special code to handle the conversion in order to be
> > portable.
>
> Where in the standard does it say that \n is a special case?

>From the draft C9X standard:
7.19.2 p2 describes text streams as organized into lines delimited by
terminating new-line characters. The rules governing whether data read
in from a file in text mode is different from the data written out to it
in text mode give special significance to new-line characters.

That was the particular part that governs the conversions mentioned
above. However, there are several other places where the standard treats
'\n' specially:

7.19.3 p3 defines line-buffered files
7.19.7.2 p2 describes how new-line affects fgets()
7.19.7.7 p2 describes how new-line affects gets()
7.19.7.10 p2 requires puts() to append a new-line

Oddly enough, 7.19.7.4 p2 does not make a similar statement about
fputs(). Was this an oversight? Should I file a defect report?

7.19.10.4 p2 requires perror() to follow the message string with a
new-line.
7.24.3.2 describes how new-line affects fgetws()
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]