Date:	Mon, 13 Jul 1998 11:02:29 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Dave Love <d DOT love AT dl DOT ac DOT uk>
cc:	Andris Pavenis <pavenis AT lanet DOT lv>,
	"Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>,
	Alexey Yakovlev <jack AT catalysis DOT nsk DOT su>, djgpp-workers AT delorie DOT com,
	fortran AT gnu DOT org
Subject:	Re: Inconsistencies between g77 v0.5.23 and v0.5.19
In-Reply-To:	<rzqpvfb2aq8.fsf@djlvig.dl.ac.uk>
Message-ID:	<Pine.SUN.3.91.980713110210.323F-100000@is>
MIME-Version:	1.0

On 12 Jul 1998, Dave Love wrote:

>  Eli> DJGPP shows that `unix' can be defined by a compiler which
>  Eli> targets other systems.
> 
> Sure, and there are already special cases for Windows32 stuff, but
> we're interested in a characteristic of Unix (POSIX, I guess).

I admit I don't know enough about how g77 is configured.  But it
puzzles me why that NON_ANSI_RW_MODES needs to be defined for native
Unix systems?  I assume that what that does is to avoid using the "b"
qualifier in an `fopen', but AFAIK using "b" does no harm on Unix, so
why do you need that define at all?

If the reason is that older non-ANSI Unix libraries don't support "b"
in a destructive way, then just test for ANSI (__STDC__) or Posix, and
if one of those is supported, always use "b".  This should solve the
problem for DJGPP, as well for any other standard-complying
environment.

Or did I miss something?

> I don't think so.  The behaviour for cygwin32, at least, depends on
> how you mount the file system, not on the library intrinsically.

True, but AFAIK using "b" won't hurt, regardless of how the file
system is mounted.

>  Eli> Since the patch is for configure.in, the DJGPP version *must* be
>  Eli> built by running the configure script.
> 
> But not necessarily natively under DJGPP.

The DJGPP port of Bash is perfectly capable of running GNU configure
scripts natively, even on plain DOS.  I have been doing that for
almost two years now (although never for g77), with no problems at all.

- Raw text -