From:	marcus AT bighorn DOT dr DOT lucent DOT com (139a80000-HallMDR313237x10)
Subject:	Re: smtp mail failed
15 Oct 1998 11:55:25 -0700 :
Message-ID:	<199810141617.KAA04778.cygnus.gnu-win32@chorus.dr.lucent.com>
Reply-To:	"139a80000-HallM(DR3132)37x10" <marcus AT bighorn DOT dr DOT lucent DOT com>
To:	gnu-win32 AT cygnus DOT com

> As I've stated on my web pages under my Personal Reflections on this
> subject, IF YOU DEPEND ON THE BINARY MODE MOUNT SETTING THEN YOU ARE
> MASKING A PROBLEM WHICH WILL EVENTUALLY BYTE YOU SOMEWHERE ELSE. 
> Consider yourself bytten.
> 
> I suggest that you get the source code and find all of the open/fopen
> statements and properly add the necessary file mode processing
> switches.  The only truly way to get rid of this for good is to
> properly port the code and be specific about what mode your file
> should be processing in.
> 
> PORTERS OF SOFTWARE, please, don't depend on the binary mode mount
> setting!!  Make the appropriate changes to the open/fopen statements.

While I agree 100% with this view, there are some difficulties that are
particularly apparent with archive software.  If tar is unpacking a file,
(or packing it, for that matter) is it a binary file or a text file?
Somehow, tar/zip/whatever must find out whether to open the file in text
or binary mode, yet there seems to be no definitive way to tell which.
Do you try to see if the file has all characters < 0x100 and line breaks
every so often to call it a text file?  What about various meta-character
escapes (for extended character sets, bold/italic/underline, etc.).  What
if an executable file actually does contain '\n' every so often.  These
heuristics are bound to make mistakes, but what better way is there to
tell?

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -