Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: fread a file of unknown size Date: Sun, 08 Mar 2015 18:43:39 -0700 Organization: None to speak of Lines: 51 Message-ID: <871tkz3pys.fsf@kst-u.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="13889"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TxmoorM+4OJE6tMcd8UwC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:AU1fUwd1iCSCtXO02qtHZoq4ch8= sha1:K/yJXLo2u5qyLnuRCI4bpXdsueA= Xref: csiph.com comp.lang.c:58010 James Kuyper writes: > On 03/08/2015 02:59 PM, Richard Heathfield wrote: >> On 08/03/15 18:47, ruben safir wrote: >>> if you use fread to read a file of unknown size with a set buffer size >>> of say 500 bytes, when you get to the end of the file you are likely to >>> read a stub of 500 bytes of info and the eof marker. >>> >>> And fread will not red that block >> >> fread ought to return the number of bytes read. Instead, it returns the >> number of blocks. I expect there was a good reason once. > > I gather that there are systems, or at least particular devices on some > systems, where the number of bytes read will always be a multiple of a > block size characteristic of that device. But fread() is defined as a sequence of calls to fgetc() (though of course it doesn't literally have to call fgetc()). N1570 7.21.8.1p2: The fread function reads, into the array pointed to by ptr, up to nmemb elements whose size is specified by size, from the stream pointed to by stream. For each object, size calls are made to the fgetc function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object. The file position indicator for the stream (if defined) is advanced by the number of characters successfully read. If an error occurs, the resulting value of the file position indicator for the stream is indeterminate. If a partial element is read, its value is indeterminate. > Even on systems where that is not true, if the file I'm reading has a > fixed record size, a valid read from an undamaged file will always read > in an integer number of records, so it still makes sense. fread() attempts to read a specified number of elements, where you can specify the size in bytes of each element. The question is, what do you want to do if reading an element (record) is only partly successful. Say you're reading 1024-byte records from a file that's 10752 bytes long (that's exactly 10.5 records). If you care how many bytes of that last partial record were read, use a size of 1. If you don't care (i.e., if a partial read is simply a failure), use a size equal to the record size. I discussed this issue here: http://stackoverflow.com/a/8589688/827263 -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"