>On Wed, 8 Mar 2000, Per Mildner wrote:
>
>> /* [PM] changed from count < file_size to count <= file_size */
>> if (0 < count && count <= file_size)
>> result = xrealloc (result, count + 2); /* why waste the slack? */
>
>Sorry, I don't understand this change. If the amount of data read from
>the file is the same as we thought when we allocated the buffer, why do
>we need to reallocate it? The call to xrealloc is only justified if you
>read less, since that means your buffer wastes space.
>
>The relevant context here is of DOS/Windows systems where reading a file
>typically strips the CR characters from each line. For a large document
>with lots of lines, you can end up wasting several tens of KBytes, which
>is enough not to ignore it.
>
>(Evidently, Cygwin reads the files in binary mode, so it doesn't belong
>to the above class of systems. But in that case, it should behave like a
>Unix box, where you always read the exact amount of bytes as returned by
>the call to stat.)
>
>So could you please explain the need for this change, and exactly how
>does the current source cause Permission Denied because of this issue?
For some reason (I think because O_BINARY becomes defined) the
VMS/WIN code gets used on cygwin. It is possible that this is wrong
but I think not since cygwin too strips CR characters, at least for
some files/mounts.
However, the "OS may strip CR characters"-branch of the code will,
incorrectly, fail if the number of bytes read is actually exactly the
same as the size reported by the system. This happens for some files
under cygwin.
The code change makes the "size equals number of bytes read" case be
treated the same as the "size is larger than the number of bytes
read"-case instead of being treated as an error. The downside to this
is that the xrealloc will be called unneccesarily in this case. You
could add a special case but, unless xrealloc is rather stupid, the
call to xrealloc should be a no-op.
--
Per Mildner, PhD [EMAIL PROTECTED]
Swedish Institute of Computer Science
