Re: libstdc++/6047: weird behaviour when reading from a pipe through an ifstream

Re: libstdc++/6047: weird behaviour when reading from a pipe through an ifstream

[bkoz]

Synopsis: weird behaviour when reading from a pipe through an ifstream

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Apr  9 12:20:24 2002
Responsible-Changed-Why:
    Mine.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6047

Re: libstdc++/6047: weird behaviour when reading from a pipe through an ifstream

[paolo]

Synopsis: weird behaviour when reading from a pipe through an ifstream

State-Changed-From-To: analyzed->closed
State-Changed-By: paolo
State-Changed-When: Thu Nov 21 03:47:23 2002
State-Changed-Why:
    Duplicate of libstdc++/5799.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6047

Re: libstdc++/6047: weird behaviour when reading from a pipe through an ifstream

[bangerth]

Synopsis: weird behaviour when reading from a pipe through an ifstream

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Wed Nov  6 13:53:02 2002
State-Changed-Why:
    This behavior still exists with 3.2.1pre and 3.3CVS

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6047

libstdc++/6047: weird behaviour when reading from a pipe through an ifstream

[benko]

>Number:         6047
>Category:       libstdc++
>Synopsis:       weird behaviour when reading from a pipe through an ifstream
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 23 01:16:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Benko Pal
>Release:        3.0.4
>Organization:
>Environment:
i686, SuSE 7.3, glibc 2.2.4
>Description:
When two programs communicate through fifos and handles them
with std::fstreams, then flushing on the writing side does
not make the contents appear on the reading side.  The
reading side only sees the data when the writing buffer is
overrun or the writing side closes the buffer.

A test case:

------------------------------------------
#ifdef WORKAROUND
# include <cstdio>
#endif /* WORKAROUND */
#include <fstream>
#include <iostream>


int
main()
{
#ifdef WORKAROUND
  std::filebuf b(std::fopen("/tmp/pipe", "r"), std::ios_base::in, 1);
  std::istream in(&b);
#else /* ! WORKAROUND */
  std::ifstream in("/tmp/pipe");
#endif /* WORKAROUND */
  char          c;

  while (in.get(c))
    std::cout.put(c);
  
  return 0;
}
-------------------------------------------

In an other shell do

$ rm -f /tmp/pipe 
$ mkfifo /tmp/pipe
$ cat > /tmp/pipe
hallo
world
^D
$ 

If the program above is compiled with 3.0.*, and run, then
"hallo" and "world" appear together, after ^D is pressed in
the writing shell.
Compiling with 2.95.3, "hallo" appears when I hit <enter> in
the writing shell, separately from "world", so this is a
sort of regression.  An equivalent C program behaves like
2.95.3, compiled with either compiler.  This behavior is
very important for me, without this the two programs just
keep waiting for each other.

By defining WORKAROUND I get the expected result, but it's a
bit inconvenient to initialise a stream like this.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: