Possible stream IO library bug

Hello,

Consider the following program:

#include <stdio.h>

main()
{
FILE *fp;

fp = fopen(“file”, “w+”); // create for r/w
fprintf(fp, “some data\n”);
fgetc(fp);
fgetc(fp);
fclose(fp);
}

When you run this, “file” contains:

some dat [without the trailing \n]

As if every fgetc(fp) call eats back up what was written to the stream
buffer. The same effect occurs with other reading stream function like
fgets or fscanf.

Am I doing something wrong?

a.r.g.a.,
t.i.a.,

rick

OS info:
QNX425 + latest patches
Watcom 10.6 + latest patches (I think)

Just when I posted, I saw this note in the docs:

‘‘When a stream is opened in update mode, both reading and writing may
be performed. However, writing may not be followed by reading without
an intervening call to the fflush() function, or to a file-positioning
function (fseek(), fsetpos(), rewind()). Similarly, reading may not be
followed by writing without an intervening call to a file-positioning
function, unless the read resulted in end-of-file.’’

So I think that’s the problem. sigh



Rick Lake wrote:

Hello,

Consider the following program:

#include <stdio.h

main()
{
FILE *fp;

fp = fopen(“file”, “w+”); // create for r/w
fprintf(fp, “some data\n”);
fgetc(fp);
fgetc(fp);
fclose(fp);
}

When you run this, “file” contains:

some dat [without the trailing \n]

As if every fgetc(fp) call eats back up what was written to the stream
buffer. The same effect occurs with other reading stream function like
fgets or fscanf.

Am I doing something wrong?

a.r.g.a.,
t.i.a.,

rick

OS info:
QNX425 + latest patches
Watcom 10.6 + latest patches (I think)