View Single Post
Old 14th April 2009
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Thanks BSDfan666 and TerryP again, that is really helpful stuff. It looks like fread() may be the missing piece. In trying to understand the origins of my confusion on this there seem to be 3 factors:

1) There are a lot of similar functions available here. Although I was aware of the distinction between those using stdio FILE*'s and the lower level ones using file descriptors, I wasn't aware of lseek(), and it seems I had forgotten about fread() due to:

2) I don't work with these things on a very regular basis, so things get fuzzy .

3) The program was originally developed on Linux, where fseek() and read() seem to work together ok. (BTW a quick check on SunOS showed it was ok there too.) This is good in a way, but it led to a false sense of security as to the general situation.

Quote:
Originally Posted by TerryP
I've never tried to mix standard I/O functions with I/O system calls (why does anyone need to do that, normally?)
I guess in my case I just found the read() interface a bit cleaner, combined with not having problems with it previously. Live and learn ...

Quote:
So if it's not reading the specified amount, I would rather assume it hit EOF and returned what was read up to that point (i.e. a number of bytes that is > 0 but < 2352)
Agreed, that was my assumption too. In the little demo program I wanted to do an extra read just to make sure there was no more. Of course it could have checked for EOF explictly then too, but this was getting beyond the first-order problem and I wanted to keep it short and clear.

So ... yesterday I re-wrote the thing to use lseek() [pointed out by ephemera]. But it seems I should really use fread() and re-assess things concerning lseek vs fseeko.

Thanks again for all the patient replies.
Reply With Quote