hi
Im learning C programming in linux and book gave a warning that when file is open for reading and writting the following restrictions apply:
-Output cannot be directly followed by input without intervening fflush,fseek or rewind
-Input cannot be directly followed by output without intervening fseek,fsetpos or rewind
Why these restrictions? What would happen if we didn't call one of those intervening functions?
thank you for your help
It has to do with buffering. If the information you've chosen to write is buffered still, meaning it hasn't actually been written to disk, then you go to read, the read may occur before the actual write has taken place. As such, your file position will be off, and you'll not get what you expect to. It, the rule, is there to save you from pulling your hair out tracking down wierd behavior in code that otherwise looks like it should work.
Quzah.
Hope is the first step on the road to disappointment.
hi
I see the logic in "if you write to file first,you must call fflush() before reading from file".
But I don't understand why you must call rewind() or fseek() after fread() but before fwrite(). As far as I know,when you read from file you get the result back instantly and so I see no danger that pointer to position in file will be moved by fwrite() before actual read takes place?
It's confusing
thank you for helping me
If you fread() a record with the intent to modify it, then you need to rewind() or fseek() back to the start of that record before you fwrite() it back out again.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
So if you don't want to modify it, but instead write from the point on where fread() stoped reading then no need for fseek()?If you fread() a record with the intent to modify it, then you need to rewind() or fseek() back to the start of that record before you fwrite() it back out again.
Is this also important when you use fread() and fwrite() on full duplex socket?I can't see why since sockets have separate receive and send buffers and so even if you fwrite() to a socket,and then immediately fread() from it,it should have no effect since you read from differend buffer than the one you write to?
> write from the point on where fread() stoped reading then no need for fseek()?
Correct
> fread() and fwrite() on full duplex socket?
Sockets are accessed using descriptors, not FILE* handles, so accessing them using fread() and fwrite() is not applicable.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I will probably never use it but I'd like to know regardless why same rules(according to my book) apply for sockets as they do for standard files(when using fread() and fwrite())?
Are there two file position pointers used for sockets or only one...?
thank you for taking the time
> why same rules(according to my book) apply for sockets as they do for standard files(when using fread() and fwrite())?
Which book?
Like I said, sockets use descriptors, and there is a separate buffer for reading and writing, and each buffer is considered to be either read-only or write-only. In that respect, they're a lot like a pair of pipes to some remote process.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Unix network programming.But I may have miss-interpret what he was saying
thank you very much for all your help
If there's one thing you can count on, it's Stevens being right about Unix network programming. I'm going to lay odds tht you misunderstood his verbage.Originally Posted by failure_to
Unix network programming.But I may have miss-interpret what he was saying
thank you very much for all your help
Quzah.
Hope is the first step on the road to disappointment.
Probably because you're being annoying and keep bumping your thread.
You're misunderstanding the concept of buffering. If it is "buffered", then it is currently sitting in memory. You flush your stream so that the buffer is written, thus, the buffer is now empty.
"Non-buffered" IO means that instead of being loaded to a buffer, or written to a buffer, the IO happens immediately. Commonly people want their keyboard input non-buffered. "How do I read a key press?" (That sort of thing.) So if buffering did not occur, your write would immediately take place, and the file pointer would be immediately moved when you told it to write. If it's buffered, then likely the pointer won't be updated until you've actually flushed the stream.
Quzah.
Hope is the first step on the road to disappointment.
