468,242 Members | 1,828 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,242 developers. It's quick & easy.

Re: Possible read()/readline() bug?

To followup on this:

Terry: Yes, I did in fact miss the 'buffer' parameter to open.
Setting the buffer parameter to 0 did in fact fix the test code that I
gave above, but oddly, did not fix my actual production code; it
continues to get the data as first read, rather than what is currently
on the disk. I'm still investigating why.

Carl: I tried the above test code, without 'buffer=0' in the open, but
with a flush added before reads in the appropriate places. The flush
made no difference; readline continued to return the old data rather
than what was actually on the disk. So, flush isn't the answer. I
suppose that means that, when the document states it flushes the
buffer, it's referring to the output buffer, not the input buffer.
Oct 23 '08 #1
3 1789
On Oct 23, 9:48 am, Mike Kent <mrmak...@cox.netwrote:
To followup on this:

Terry: Yes, I did in fact miss the 'buffer' parameter to open.
Setting the buffer parameter to 0 did in fact fix the test code that I
gave above, but oddly, did not fix my actual production code; it
continues to get the data as first read, rather than what is currently
on the disk. I'm still investigating why.

Carl: I tried the above test code, without 'buffer=0' in the open, but
with a flush added before reads in the appropriate places. The flush
made no difference; readline continued to return the old data rather
than what was actually on the disk. So, flush isn't the answer. I
suppose that means that, when the document states it flushes the
buffer, it's referring to the output buffer, not the input buffer.
Something odd is going on for sure. I had a couple of theories but
then I tested it on both Windows XP and AIX and could not reproduce
the problem even using the default buffer setting. As soon as I do a
seek and read it gives me the new data. I wonder if other people can
test this out on different operating systems and file systems and
detect a pattern.
Oct 23 '08 #2
Mike Kent wrote:
To followup on this:

Terry: Yes, I did in fact miss the 'buffer' parameter to open.
Setting the buffer parameter to 0 did in fact fix the test code that I
gave above, but oddly, did not fix my actual production code; it
continues to get the data as first read, rather than what is currently
on the disk. I'm still investigating why.
What OS is your test code one? What OS is your production code on? As
mentioned read{line} will mirror the OS's underlying stdio.

j

Oct 23 '08 #3
Mike Kent wrote:
To followup on this:

Terry: Yes, I did in fact miss the 'buffer' parameter to open.
Setting the buffer parameter to 0 did in fact fix the test code that I
gave above, but oddly, did not fix my actual production code; it
continues to get the data as first read, rather than what is currently
on the disk. I'm still investigating why.
Some hardware, OS?
How do you know what is currently 'on disk'? Even with 'buffering'
turned off, the disk is read and written in 'blocks'. 512 bytes was
common on unix. I suspect it is larger on Linux now. (4k on Windows,
typically). You *might* be seeing something as deep as the driver for a
particular disk. Good luck.
Carl: I tried the above test code, without 'buffer=0' in the open, but
with a flush added before reads in the appropriate places. The flush
made no difference; readline continued to return the old data rather
than what was actually on the disk. So, flush isn't the answer. I
suppose that means that, when the document states it flushes the
buffer, it's referring to the output buffer, not the input buffer.
Yes, I checked C99 reference

Oct 24 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by washu | last post: by
18 posts views Thread by jas | last post: by
2 posts views Thread by Tim Bücker | last post: by
5 posts views Thread by Dara Durum | last post: by
6 posts views Thread by Sean Davis | last post: by
1 post views Thread by Steven D'Aprano | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.