Q: std::getline and portability

Hi!

I've just been bitten by the famous Windows newline issue, i.e.
tried to read a textfile written by a windows application on
an unix platform. When reading a line with

std::getline(input,buf);

GCC 3.2 leaves a trailing '\r' in buf.
Is this standard conformant? My impression was that getline
should remove '\r\n' as well as '\n'.

Thanks in advance & regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frank DOT schmitt AT 4sc DOT com

re: Q: std::getline and portability

On 01 Sep 2003 12:29:59 +0200, Frank Schmitt <frank.schmitt@4sc.com> wrote:[color=blue]
> Hi!
>
> I've just been bitten by the famous Windows newline issue, i.e.
> tried to read a textfile written by a windows application on
> an unix platform. When reading a line with
>
> std::getline(input,buf);
>
> GCC 3.2 leaves a trailing '\r' in buf.
> Is this standard conformant? My impression was that getline
> should remove '\r\n' as well as '\n'.[/color]

Assuming the program is running on a system that uses \n as the
line terminator (such as every unix I've heard of) then yes.

When you transfer text files between systems you need to convert them
to the destination systems format. The line terminator is the most
obvious conversion, but occassionaly there are character set issues too.

--
Sam Holden

re: Q: std::getline and portability

Frank Schmitt wrote:[color=blue]
> Hi!
>
> I've just been bitten by the famous Windows newline issue, i.e.
> tried to read a textfile written by a windows application on
> an unix platform. When reading a line with
>
> std::getline(input,buf);
>
> GCC 3.2 leaves a trailing '\r' in buf.
> Is this standard conformant? My impression was that getline
> should remove '\r\n' as well as '\n'.[/color]

It is conformant AFAIK. A platform only needs to be prepared for its own
file format.

--
Attila aka WW

re: Q: std::getline and portability

Frank Schmitt <frank.schmitt@4sc.com> writes:
[color=blue]
> Hi!
>
> I've just been bitten by the famous Windows newline issue, i.e.
> tried to read a textfile written by a windows application on
> an unix platform. When reading a line with
>
> std::getline(input,buf);
>
> GCC 3.2 leaves a trailing '\r' in buf.
> Is this standard conformant? My impression was that getline
> should remove '\r\n' as well as '\n'.[/color]

Only if (a) you opened the file in text mode and *not* in binary mode,
and (b) your platform defines CR LF as a newline (like windows,
but not like unix or mac).

re: Q: std::getline and portability

Frank Schmitt <frank.schmitt@4sc.com> writes:
[color=blue]
> Hi!
>
> I've just been bitten by the famous Windows newline issue, i.e.
> tried to read a textfile written by a windows application on
> an unix platform. When reading a line with
>
> std::getline(input,buf);
>
> GCC 3.2 leaves a trailing '\r' in buf.
> Is this standard conformant?[/color]

Yes.
[color=blue]
> My impression was that getline
> should remove '\r\n' as well as '\n'.[/color]

Not on unix. On unix \n is just LF, so that is all that is
removed. The CR windows put there is not part of a unix newline,
and is left alone. If you want it removed you must do so
yourself.

re: Q: std::getline and portability

llewelly <llewelly.at@xmission.dot.com> writes:
[color=blue]
> Frank Schmitt <frank.schmitt@4sc.com> writes:
>[color=green]
> > Hi!
> >
> > I've just been bitten by the famous Windows newline issue, i.e.
> > tried to read a textfile written by a windows application on
> > an unix platform. When reading a line with
> >
> > std::getline(input,buf);
> >
> > GCC 3.2 leaves a trailing '\r' in buf.
> > Is this standard conformant?[/color]
>
> Yes.
>[color=green]
> > My impression was that getline
> > should remove '\r\n' as well as '\n'.[/color]
>
> Not on unix. On unix \n is just LF, so that is all that is
> removed. The CR windows put there is not part of a unix newline,
> and is left alone. If you want it removed you must do so
> yourself.[/color]

Ah, I feared so.

Thanks to all for the quick & informative answers
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frank DOT schmitt AT 4sc DOT com