Re: Patch: Initialise new file space to zero for Beos

[fnf at toadfish dot ninemoons dot com]

> : So I don't think you should write your patch as a change to bfd_seek.
> : I think you should write a version of fseek which you put into
> : libiberty, and you should fix up the libiberty configuration to build
> : that version of fseek on BeOS.  It may turn out to be convenient to
> : give it a different name, and to use an appropriate #define when
> : building BFD, which would be fine by me.
> 
> OK, well I have a patch to libiberty (see below) that creates a new
> function called zero_fseek() for BeOS hosts. 

Although this solution will work, I have serious concerns about 
performance issues.

> + int
> + zero_fseek (stream, offset, whence)
> +      FILE * stream;
> +      long   offset;
> +      int    whence;
> + {
> +   file_ptr eof;
> +   file_ptr pos;
> + 
> +   /* Get the current file position, and the length of the file.  */
> +   pos = ftell (stream);
> +   fseek (stream, 0L, SEEK_END);
> +   eof = ftell (stream);

If this function is called everytime gcc, gas, ld, etc wants to do an
fseek of any kind, then there will be at least two ftell calls and one
fseek before the actual seek that needs to be done.

As far as I know, part of the reason that BeOS does not zero the new
blocks added to a file by seeking past the end of it is that we wish
to avoid the performance overhead (small as it might be) of always
zeroing space that is probably going to be simply overwritten anyway.
This additional overhead could be an issue with the BeOS mission of
being a media oriented OS, where any overhead in I/O operations needs
to be scrutinized closely.

Given that this BeOS feature is also a potential security hole, it is
possible that the low level BeOS behavior may change.  This would make
the original patch Nick provided for bfd, as well as the current
proposed change, unnecessary.  For the moment I think we can live with
the bfd change, even if we have to maintain it as a Be local change to
the tools.  If indeed the low level behavior of BeOS will NOT change,
then the more general solution of wedging zero_fseek into the tools
via the libiberty library may be a better longterm solution.

Note that the only bug we have observed in the tools to date is the
assembler writing random data to parts of object files that are
allocated by seeking past the current end of the file and then never
overwritten with "real data".

-Fred