This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Clear new space in fseek extended patches
- To: fnf at be dot com
- Subject: Re: Clear new space in fseek extended patches
- From: DJ Delorie <dj at delorie dot com>
- Date: Wed, 30 Aug 2000 21:29:52 -0400
- CC: nickc at redhat dot com, binutils at sources dot redhat dot com, fnf at ninemoons dot com
- References: <200008310107.SAA03684@gofish.ninemoons.com>
> Do you mean write anywhere in the file after doing an fseek or only
> when you write after the file location corresponding to where the
> fseek that extended the file started? I suspect you mean the latter
> and that the zero padding should only be to the extent necessary to
> fill any holes in a sparse file.
The latter, but let me clarify.
If the program does, say, 100 seeks to random places, and the result
is that the file pointer is beyond EOF, then the program does 100
writes, the first write - and *only* the first write - does an ftell
to see if the file pointer is beyond EOF, and fills if needed. The
remaining writes do not need to check, because there were no
intervening fseeks.
> > Merely fseeking past EOF shouldn't modify the file.
>
> This does seem to be the standard UNIX behavior.
Consider the attached test case. In Unix, it yeilds an 11-byte file
with the string "hellothere\n" in it. It does *not* create a 100-byte
(or more) file (unless you put an fprintf between the fseeks). If you
take out the second fseek and the second fprintf, it yeilds a 5-byte
file.
> If you can be a little more precise about what you mean I'll concoct
> a testcase and try it out on BeOS.
#include <stdio.h>
main()
{
FILE *f = fopen ("dj.out", "w");
fprintf (f, "hello123");
fseek (f, 100, 0);
fseek (f, 5, 0);
fprintf (f, "there\n");
fclose (f);
}