Re: Handling text files

Cosmin,

>> You're overlooking Mac OS.  It would be possible to add OS-of-origin
>> tests to the conversion (assuming the OS-made-by byte could be trusted,
>> which is highly questionable), but I'm not sure that's a good idea.

> MacOS up to v9 uses exclusively CR, doesn't it? Files that contain
> "text\r\r\ntext\r\r\ntext\r\r\n" are unlikely to come from MacOS.

Perhaps, but now you're making an additional assumption--the current
conversion code sees, at most, one \r\r\n and decides on that basis.
(In fact, I'm pretty sure it sees only \r\r before making a decision.)
Doing a global check would require a two-pass approach and is unlikely
to be a popular change.

> There are a couple of problems having me maintaining unzip, however.
> I don't always answer emails right away,

Christian sometimes goes for months at a time, Onno is even worse...I'm
not sure that would rule anyone out at this point.

> and I only have Windows,
> Cygwin and Linux available for testing.

Win32 and something Unix-like fully covers the basics.  (Both of those
can run plain DOS, too.)  There are still a few platform-specific folks
(like Darren) testing other systems for breakage.

> Furthermore, I have little
> sympathy towards the compilers that don't know about ANSI C,

14 years ago, or even seven, that would have been a bit extreme.  But
I tend to feel the same way these days--string concatenation and clean
prototypes are just too useful.  It's really more a matter of "whoever
writes the code makes the decisions"--not completely unilaterally, but
that definitely gets the biggest vote.

> I personally value code reuse above a self-contained compilable bundle
> (e.g. I would prefer integrating zlib into the Info-ZIP code),

I don't see how an integrated zlib promotes code reuse; what do you
do when the next version is released?  If you want it self-contained,
well, it already is (that is, without zlib).

Also keep in mind that zlib provides only deflate.

> > > 3). The way that zip distinguishes between binary vs. text files can
> > > never be 100% precise, and yet the current method (which AFAIK is
> > > inherited from PKZIP) guesses wrong many times. I propose to consider
> > > any file that contains any single non-printable control character, a
> > > binary file.
> >
> >That's not a bad idea, although the current approach was chosen for
> >performance reasons.

> My proposed method does not incur any performance penalty.
> In set_file_type() from trees.c, you set the file type as follows:
>   set file type to ASCII
>   for n in { 0, 1, ..., 8, 14, ... 31 } do
>     if dyn_tree[n].Freq != 0 then
>       set file type to BINARY
>     end if
>   end for

Ah, slick.  But does the text/binary flag go only in the central header
or also in the local?  Processing the whole file destroys streamability
in the latter case (unless the extended local header can contain it,
too, but I'm guessing not).  I should just check myself, but it's late
and I'm lazy.

Greg