Message-ID: <B0000085023@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Tue, 27 Apr 1999 14:52:18 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: v2.03: wrapping up
CC: djgpp-workers AT delorie DOT com
References: <B0000085011 AT stargate DOT astr DOT lu DOT lv>
In-reply-to: <Pine.SUN.3.91.990427130938.971B-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.02b14)
Reply-To: djgpp-workers AT delorie DOT com

On 27 Apr 99, at 13:36, Eli Zaretskii wrote:


> >  	lib/specs). I haven't met any problems with it. Yesterday I tried to look
> > 	at sources of emacs-19.34 and didn't find any problems when building it.
> > 	Grepping sources also shows that all should be Ok.
> 
> I don't understand why do you say ``all should be Ok''.  In the Emacs 
> 19.34 distribution, the files src/msdos.c and src/dosfns.c check whether 
> __DJGPP_MINOR__ is 0 (for some bugs in v2.0).  Current Emacs 20.3 sources 
> check for 2.02 or later (for some features missing in v2.01, like 
> sigprocmask).

It took some minutes for me to grep sources and see that stdio.h is included
before using __DJGPP_MINOR__ in these both files so we have correct definition of 
__DJGPP_MINOR__. (I touched sources of EMACS for DJGPP first time at all). That is why 
I said all is Ok. Not only because I built EMACS-19.34. 

> This is not limited to Emacs, either.  For example, the sources for dvilj 
> program (from the TeX/Web2c distribution) check for v2.02 or later, to 
> work around a problem in earlier stubs with inherited file handles; the 
> next version of Make will check for v2.02 as well, because we now have 
> sys_siglist[] and psignal.
> 
> And this is only off the top of my head.  The problem is real, believe 
> me.
> 
> > 	I myself haven't seen any problems. Binaries of DJGPP port of egcs-1.1.2
> > 	does not define DJGPP_MINOR in specs. Therefore it would be easy to test
> > 	this with this version.
> 
> It is not easy at all to test this.  How do you test whether anything is 
> broken in large and complex programs like Make or Emacs?  Most probably,
> you won't see any trouble until you create some very special situation; 

I suggest following way of testing:
	grep sources to find where DJGPP_MINOR is used 

	add
		#if defined(__DJGPP__) && !defined(__DJGPP_MINOR__)
		#error DJGPP_MINOR is not defined
		#endif
 	before using this macro

And we'll get places where we have problems. I think currently such check could even stay 
in released sources.

> and to do that, you need a thorough understanding what exactly do those 
> #ifdef's try to solve and under what conditions are these solutions 
> needed, and then analyze the source files and the headers they include to 
> see if maybe they include stdio.h at the right time.
> 
> Alternatively, you need to remember what were the problems which caused 
> that special code to be written, and how to recreate those problems.  I 
> don't know how much time will it take me to recall the problems I solved 
> years ago.
> 
> Like I said: it's a maintainer's nightmare.

If we're not trying to find reasonable way of testing
 
> Is it really that hard to add a few lines to GCC so that it expands 
> %C_INCLUDE_PATH% and passes -imacros to cpp?  Maybe we should do that 
> instead of arguing.

At first CPP from ports gcc-2.8.X or egcs knows where to find standard include
file directories even without %C_INCLUDE_PATH%. So expanding 
%C_INCLUDE_PATH% maybe not enough.

Also I don't like that way. I don't like to introduce similar things. 

Andris