X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: Andris Pavenis <pavenis AT latnet DOT lv>
To: djgpp-workers AT delorie DOT com
Subject: Re: Problems with long command lines in DJGPP
Date: Tue, 25 Jan 2005 11:05:26 +0200
User-Agent: KMail/1.7.91
References: <200501241804 DOT 18985 DOT pavenis AT latnet DOT lv> <01c5024d$Blat.v2.4$c48f7340 AT zahav DOT net DOT il>
In-Reply-To: <01c5024d$Blat.v2.4$c48f7340@zahav.net.il>
Cc: "Eli Zaretskii" <eliz AT gnu DOT org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200501251105.26190.pavenis@latnet.lv>
X-Virus-Scanned: by amavisd-new at fgi.fi
Reply-To: djgpp-workers AT delorie DOT com

On Monday 24 January 2005 21:48, Eli Zaretskii wrote:
> > From: Andris Pavenis <pavenis AT latnet DOT lv>
> > Date: Mon, 24 Jan 2005 18:04:18 +0200
> >
> > I don't like idea about increasing the default transfer buffer size.
> >
> > Perhaps it would be better in dosexec.c to write command line arguments
> > to temporary file and after that use @filename instead when transfer
> > buffer is to small.
>
> Is it really wise to make such radical changes to dosexec.c at this
> point?  

Maybe it is possible to make them in a such way to minimize 
possibility of any harm while current command line limit is not reached.

> This problem can be easily fixed by changing the GCC bootstrap 
> scripts to stubedit xgcc.exe, no?

Maybe. But it's not only case where this problem can occur. 

> Alternatively, we could enable the (currently disabled) code in
> dosexec.c that reallocates the transfer buffer if the original size is
> not enough.  See the function check_talloc there.

Tried. Initially it didn't compile (-Wall -W... -Werror) with gcc-3.4.3. When
I got it to compile and got it really allocate a bigger buffer, then it still 
didn't work. Also it is limited to 64K. 

One of idea how it could be done:

1) before putting arguments string into transfer buffer, estimate whether
there is enough place for entire operation. If enough continue as earlier
2) if the place is insufficient then allocate DPMI descriptor where to 
backup current transfer buffer and backup it (perhaps malloc is not OK 
here)
3) write command line to temporary file. This will overwrite transfer buffer,
but we have backup
4) restore previous contents of transfer buffer and release previously 
allocated descriptor
5) put @filename instead of full argument string to transfer buffer
6) after that we may continue as earlier, only temporary file must be 
removed when it is no more needed.

For debugging purposes it could be possible to add a mode in which 
this way is used always (perhaps preprocessor definition)

Possibility to backup and restore transfer buffer could sometimes usefull
also in other places for debugging if one wants to log something while 
transfer buffer is in use.

Andris