This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with line buffering and getc function on 1.7.33.

On 11.03.2016 14:14, Marco Atzeri wrote:
On 11/03/2016 22:57, Kaz Kylheku wrote:
On 11.03.2016 12:08, Yaakov Selkowitz wrote:
On 2016-03-11 13:16, Kaz Kylheku wrote:

On a Cygwin installation version 1.7.33-2(0.280/5/3), I encountered
an odd issue.

This is a 15-month old release which is no longer supported. Please
update to 2.4.1.

Do you mean, "Please update to 2.4.1, it is fixed there!"
or do you mean "You haven't done enough with that minimal
C repro case; please keep investigating against
the latest code?"

#2 please verify if the issue is still present in the last code.
We don't have the bandwith to check claims on older release.
on 2.4.1 the output is:

$ ./test_stream.exe
received REQUEST
 from client
 from server

That confirms that the issue is still there.

We can reproduce the problem with just file streams using
a much simpler program:

#include <stdio.h>

int main(void)
  FILE *out = fopen("file", "w+");
  setvbuf(out, (char *) NULL, _IOLBF, 0);
  fseek(out, 0, SEEK_SET);
  putc('a', out);
  putc('b', out);
  putc('c', out);
  putc('d', out);
  putc('e', out);
  putc('\n', out);
  return 0;

The contents of file end up being "\n": one empty
line, instead of "abcde\n":

  $ cat file


The necessary ingredients seem to be: open the stream for update;
put into line buffered mode; do some input. In this program,
replacing putc with fputs doesn't make the problem go away;
the workaround isn't working:

  fputs("a", out);
  fputs("b", out);
  fputs("c", out);
  fputs("d", out);
  fputs("e", out);
  fputs("\n", out);

However, if we do it as one string, then the file does contain
the correct line:

  fputs("abcde\n", out);

This sequence also gets us correct file contents:

  fputs("ab", out);
  putc('c', out);
  putc('d', out);
  putc('e', out);
  putc('\n', out);

HOWEVER, these distracting effects are because GCC is
optimizing one-character fputs calls into _fputc calls.
Annoyingly, this happens even with gcc -O0.

The clearerr and fseek calls are red herrings; they seem to make
make no difference. I put in the fseek for formal ISO C compliance:
ISO C says that before performing an output operation on an update
stream whose last operation was input, we "shall" perform a
positioning operation. (No sanely implemented libc actually
breaks code that doesn't meet this silly requirement.)

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]