fread and fwrite sync 
Author Message
 fread and fwrite sync

This may be a dumb question, however I just can not figure it out.
And I did not find in FAQ.

Suppose you open a file for reading and writing, according to the Std
C, you can not have read/write followed by write/read without a
file-positioning request, fflush(), fseek() etc.  Can anybody tell me
why?  IMHO, it may not be diffcult to remove this requirement.  Is
there just one buffer for read and write?  Write and read share FILE
structure (file position)?

I have never violated the above C std rule.  just curious.  I know
there must be a justification behind it.

Thanks.

lg



Sun, 10 Jul 2005 02:57:58 GMT  
 fread and fwrite sync

Quote:

> Suppose you open a file for reading and writing, according to the Std
> C, you can not have read/write followed by write/read without a
> file-positioning request, fflush(), fseek() etc.  Can anybody tell me
> why?  IMHO, it may not be diffcult to remove this requirement.  Is
> there just one buffer for read and write?  Write and read share FILE
> structure (file position)?

This is what the C99 Rationale says:

      A change of input/output direction on an update file is
      only allowed following a successful fsetpos, fseek, rewind,
      or fflush operation, since these are precisely the
      functions which assure that the I/O buffer has been
      flushed.

--
Go not to Usenet for counsel, for they will say both no and yes.



Sun, 10 Jul 2005 03:00:27 GMT  
 fread and fwrite sync

Quote:
>       A change of input/output direction on an update file is
>       only allowed following a successful fsetpos, fseek, rewind,
>       or fflush operation, since these are precisely the
>       functions which assure that the I/O buffer has been
>       flushed.

Yes, I know what std says.  What I am asking is why this requirement
is required?  How it is implemented under the hood?  I know there must
be a reason behind it.  Otherwise why give users extra restraint?  Is
it designed to gurantee multiple process access consistency?  Could
you shed some light on this topic?

Thanks.

LG



Sun, 10 Jul 2005 07:01:09 GMT  
 fread and fwrite sync

Quote:
> >       A change of input/output direction on an update file is
> >       only allowed following a successful fsetpos, fseek, rewind,
> >       or fflush operation, since these are precisely the

                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:
> >       functions which assure that the I/O buffer has been

          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:
> >       flushed.
          ^^^^^^^^

> Yes, I know what std says.  What I am asking is why this requirement
> is required?  How it is implemented under the hood?  I know there must
> be a reason behind it.  Otherwise why give users extra restraint?  Is
> it designed to gurantee multiple process access consistency?  Could
> you shed some light on this topic?

    I believe the underlined section above is the reasoning.


Sun, 10 Jul 2005 07:05:02 GMT  
 fread and fwrite sync

Quote:

> >       A change of input/output direction on an update file is
> >       only allowed following a successful fsetpos, fseek, rewind,
> >       or fflush operation, since these are precisely the
> >       functions which assure that the I/O buffer has been
> >       flushed.

> Yes, I know what std says.

That's not the standard.  That's the Rationale, which is a
separate document that attempts to describe the committee's
reasoning behind what is in the standard.

Quote:
> What I am asking is why this requirement
> is required?  How it is implemented under the hood?  I know there must
> be a reason behind it.  Otherwise why give users extra restraint?  Is
> it designed to gurantee multiple process access consistency?  Could
> you shed some light on this topic?

The quote above leads me to believe that the committee thought
that, for whatever reason, the library should not have to take
responsibility for flushing its own buffers when file activity
shifts between input and output.  I don't know why they thought
that.  To my knowledge, all real C libraries that I have used
have not had this particular limitation.


Sun, 10 Jul 2005 07:04:00 GMT  
 fread and fwrite sync
[someone quoted the C89 Rationale]

Quote:
>>       A change of input/output direction on an update file is
>>       only allowed following a successful fsetpos, fseek, rewind,
>>       or fflush operation, since these are precisely the
>>       functions which assure that the I/O buffer has been
>>       flushed.


Quote:

>Yes, I know what std says.  What I am asking is why this requirement
>is required?  How it is implemented under the hood?  I know there must
>be a reason behind it.  Otherwise why give users extra restraint?

This is how System V did things, in the days during which the first
C standards were written.  The original BSD stdio (before mine)
worked similarly.  C89 was largely a descriptive standard -- "this
is how things work today" -- rather than a prescriptive "this is
how things SHOULD work" standard.  (There were exceptions, and in
general, those things that were X3J11 committee inventions were
the klunkiest parts of the standardized language.)

The current BSD stdio (the one I wrote) automatically does
buffer-flushing for you if needed.  It required only one structural
change as I was writing it, to split the "count" field into separate
"read" and "write" counts (one of which is always 0).  It also
required one coding addition:  the functions that handled buffer
full/empty conditions (for write/read respectively) had to notice
that they were being asked to switch I/O directions as well.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (4039.22'N, 11150.29'W)

(you probably cannot email me -- spam has effectively killed email)



Sun, 10 Jul 2005 08:00:22 GMT  
 fread and fwrite sync

Quote:
> The quote above leads me to believe that the committee thought
> that, for whatever reason, the library should not have to take
> responsibility for flushing its own buffers when file activity
> shifts between input and output.  I don't know why they thought
> that.  To my knowledge, all real C libraries that I have used
> have not had this particular limitation.

Hmm...., Maybe not.  At least one of my collegues encountered this
problem on Solaris (2.8, if I am correct).  Probably I miss sth here,
I am afraid.  Because it appears very obvious the rule is not
necessary.  Then why the first version works this "weird" way?  If you
don't flush, how it interferes your operation?  The rule may be there
for historical reasons just as the reply posts explained.  I mean for
usually fully buffered stdio, flushing or no flushing should not
matter much.

              user space       |    Kernel space
User array<---->Buffer[..] <---|---->Disk buffer <-----> physical disk
fread/fwrite(.)            read/write()

There must be some dirty details there.

Regards,

LG



Sun, 10 Jul 2005 22:22:42 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. fread, fwrite probs

2. Please Help (fread, fwrite)

3. fwrite(), fread() portability.

4. problem with fwrite / fread

5. fopen() fseek() fread() fwrite()

6. Problem with struct/array inside a struct using fread/fwrite

7. Strange byte order using fread() and fwrite()

8. fread and fwrite

9. microsoft endian problem with fread/fwrite

10. fwrite + fread problem

11. fread/fwrite guarantees

12. setvbuf, fwrite & fread

 

 
Powered by phpBB® Forum Software