On October 18, 2002 05:04 pm, Rasmus Lerdorf wrote:
> > On October 18, 2002 04:40 pm, Rasmus Lerdorf wrote:
> > > > Fixed bug #19971 (optimized the file() function).
> > > > The file() function is now also binary safe.
> > >
> > > That's a bit misleading. By definition file() cannot be binary-safe in
> > > that \n is treated specially.
> >
> > Not quite, in the old code (4.2.3) doing a file() would produce a wildly
> > inaccurate count of lines. For example, a php executable was only 2200
> > lines, while 'wc -l' and manual checks using C yielded a result of 9800
> > lines. In my mind that meant that the old code was un-safe to use on
> > binary files. The new code works properly and breaks down the file by
> > lines accurately.
> >
> > Ilia
> >
> > P.S. Thanks to Wez & Sascha we also support MAC EOL in 4.3.0, so we don't
> > look for \n specifically per say.
>
> My point is that the original data is munged once it goes through the
> file() function. In that sense it is not binary safe as there is no
> way to restore the original data.
Unless the user actually goes and modifies the data, it is very easy to
restore the original file back. The example script below will demonstrate
that the output of file() can still be safely restored.
<?php
echo md5_file("sapi/cli/php")."\n";
echo md5(implode("", file("sapi/cli/php")))."\n";
?>
Both of the md5s are identical, meaning that the file() call itself did
nothing that would corrupt the file preventing the the user from restoring
file. IMHO that means that the function is binary safe.
Ilia
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
