RE: Patch: Bug: Shell fork/exec avoidance in make-3.79.1-3

[Bernard Dautrevaux <Dautrevaux at microprocess dot com>]

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> Sent: Tuesday, June 26, 2001 10:14 PM
> To: cygwin@cygwin.com
> Subject: Re: Patch: Bug: Shell fork/exec avoidance in make-3.79.1-3
> 
> 
> On Tue, Jun 26, 2001 at 08:56:50PM +0200, Bernard Dautrevaux wrote:
> >> I've included a patch below that changes all the char[] definitions
> >> in job.c to char*.
> >
> >I don't think that is the problem; if I look at your patch 
> below, the char[]
> >definitions you change in char* are only used on AMIGA or 
> VMS, but *NOT* on
> >CYGWIN... ;-(
> 
> Sorry, no.  The original poster obviously did some research 
> here.  There
> is a definite problem between 'char *' and 'char []' in the
> default_shell definition.

Sorry for the confusion; it appears I was using the source for
make-3.79.1-2, not -3, and in -2 the ifdefs in job.c were a bit different,
so that the first ifdef read:

#ifdef WIN32_OR_CYGWIN

and thus all was working OK... It was partly my fault (and partly due to
working a bit late yesterday evening), partly due to an obvious regression
in -3 compared to -2. In fact I was even once more puzzled how well broken
code can work: I would have expected a more brutal error (like a DrWatson
popup) for a variable being used in one part of the code as a pointer and in
another as an array of chars. 

In fact the code in -2 was correct as the "char*" definition in main.c was
only present on CYGWIN and MSDOS, two cases where it was correctly defined
as char* in job.c. But of course, defining ALL default_shell as "char*" is
The Right Thing (TM).

> 
> >If you look at my previous message (posted about in paralell 
> with your),
> >you'll see that just recompiling the code without any change 
> allow me to get
> >a working make. I suspect your change (that does nothing on 
> CYGWIN) is just
> >exercising the same behaviour. IMHO it's just the cygwin 
> package that was
> >compiled in a buggy environment. 
> 
> I build make on linux, like all of my packages.  To the best 
> of my knowledge,
> I have never had a corrupted environment.  I build everything 
> in a standard
> way using standard scripts.  If I detect an error, I correct 
> the script.

I can understand this; in fact I'm working exactly in the same way (although
for mingw32) and was only compiling natively under cygwin for the first time
since several years for these tests yesterday. 

> 
> >IIRC it happens some time ago to Corinna to have a 
> screwed-up environment
> >that generated a working bash that shows a bug that disapear 
> after she
> >updates its environment. I suspect the make maintainer have 
> (or had) the
> >same problem...
> 
> I suspect that your suspicion is wrong.

Sure it it :-) Anyway, if I had noticed that you were the cygwin make
maintainer I would have not suspected this but better looked at MY
environment (that in fact WAS a bit broken because I was using a version
that was too old to show the bug...).

In fact that shows a small problem with the 'patch' level of tools: there is
no way when you look at the source code or at the executable to know which
patch level you are using: both say 3.79.1, with no patch level ;-( With the
installed tool, you can look in the update.db file, but for the source...

Anyway as this is corrected, all is fine and I must congrat all those that
find the problem.

	Bernard

> 
> cgf
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/