delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/02/02/01:01:34

From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson)
Subject: Re: ASCII and BINARY files. Why?
2 Feb 1997 01:01:34 -0800 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199702020551.QAA05565.cygnus.gnu-win32@mundook.cs.mu.OZ.AU>
Original-To: riche AT crl DOT com (Alex Stewart)
Original-Cc: gnu-win32 AT cygnus DOT com (gnu-win32)
In-Reply-To: <199701310227.AA04399@crl6.crl.com> from "Alex Stewart" at Jan 30, 97 06:27:01 pm
X-Mailer: ELM [version 2.4 PL24]
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Alex Stewart, you wrote:
> 
> > It might well be straightforward to implement 't' and O_TEXT,
> > but it would be a _bad idea_ to do so, because it would be a
> > bad idea to use those features.  Using 't' and O_TEXT would be a bad
> > idea even if they were implemented, because doing so would reduce
> > portability, rather than improving it, because they are non-standard.
> 
> So your argument is "I don't want to use it, so nobody else should be allowed
> to."?  That is, quite frankly, pathetic.

No, that's not my argument.  Please don't put words into my mouth,
especially not when they are unrelated to what I actually said.

> Addressing the portability issue, including a "t" flag in a fopen call does
> not decrease portability in any way, as it will simply be ignored by any
> libraries which do not support it.

Thank you for that information.  Where did you find this out?
Is this guaranteed by some standard?  Or is it just your assumption?
Are you sure that some future system won't treat the "t" flag in
fopen as say the "time bomb" option?

> O_TEXT will produce a compiler warning if
> it isn't defined in a header file, but it is extremely easy to avoid that with
> a simple:
> 
> #ifndef O_TEXT
> #define O_TEXT 0
> #endif
> 
> ..resulting in code which is just as portable (some might argue more portable
> because it will actually perform _properly_ on a wider number of systems).

That is a fair point.  Since using O_TEXT in this way might improve
portability, I'm not opposed to adding support for O_TEXT to gnu-win32.
However, I think that for consistency it would probably not be a good
idea to add O_TEXT without adding support for "t" in fopen, and for
reasons explained above I am still opposed to doing that, though
perhaps you may be able to persuade me otherwise, if you can convince
me of the truth of your claim that

	"including a "t" flag in a fopen call does not decrease
	portability in any way, as it will simply be ignored by any
	libraries which do not support it".

> Your arguments are therefore not only egocentric, but quite simply incorrect.

My arguments may perhaps be incorrect, but labelling them as
"egocentric" doesn't add anything to the debate.  The quality and
usefulness of this mailing list would be improved if the participants
avoided ad-hominem attacks.

-- 
Fergus Henderson <fjh AT cs DOT mu DOT oz DOT au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019