Date: Sun, 14 Apr 1996 08:31:29 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Marty Leisner <leisner AT sdsp DOT mc DOT xerox DOT com>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: O_BINARY/O_TEXT on open
In-Reply-To: <9604111455.AA18037@gemini.sdsp.mc.xerox.com>
Message-Id: <Pine.SUN.3.91.960414082333.1640I-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Thu, 11 Apr 1996, Marty Leisner wrote:

> I have an old POSIX spec...no mention of O_BINARY...glibc 1.09 docs
> don't mention O_BINARY...Stevens Advanced Unix Programming doesn't
> mention O_BINARY...Linux man pages don't mention O_BINARY...
> where is O_BINARY mentioned?  When was it introduced?

It was always there in DOS.  ANSI doesn't define it (but then ANSI 
doesn't define any functions that use it either).  I don't know if POSIX 
defines it, but I won't be surprised if it doesn't: it has no meaning on 
Unix systems.

> The default is O_TEXT...the default will break some programs...but I've
> seen much less breakage with defaulting O_BINARY than O_TEXT...
> 
> What I'm doing is hacking up the the makefile to include a file which defines
> fmode = O_BINARY to default to binary...(better than hacking up code).
> 
> I'd like to have a cleaner way to do this than hacking up the source

Since when porting utilities (especially file-oriented utilities) to 
MS-DOS can be made without hacking the sources?

I think the cleanest way is to get FSF (or at least the individuals who 
maintain the different packages) to finally recognize that some systems 
do need to know about binary files, and include O_BINARY in the original 
sources where they are needed.  They can always define it to be 0 on Unix 
systems.