From:	k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at (Oberhumer Markus)
Message-Id:	<199608052234.AAA22104@c210.edvz.uni-linz.ac.at>
Subject:	Re: Transfer buffer usage in `spawnXX'
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Tue, 6 Aug 1996 00:34:31 -0200 (MET DST)
Cc:	djgpp-workers AT delorie DOT com (djgpp-workers)
In-Reply-To:	<Pine.SUN.3.91.960728091510.23430H-100000@is> from "Eli Zaretskii" at Jul 28, 96 09:23:29 am
Return-Read-To:	markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at

===============================================================================
Markus F.X.J. Oberhumer <markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at>

Subject: Re: Transfer buffer usage in `spawnXX'
To: djgpp-workers AT delorie DOT com
===============================================================================

On 28 Jul 1996 Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

> Currently, the function that allocates space off the transfer buffer
> (`talloc' on `src/libc/dos/process/dosexec.c) doesn't check if the
> transfer buffer space was exhausted, and will happily overwrite DOS memory
> if e.g. your environment size (or the command line) is sufficiently 
> large.  There are two ways of repairing this:
> 
> 	* detect when all the buffer space has been used up, and return 
> with -1 and errno = ENOMEM.
> 
> 	* as above, but when the transfer buffer is exhausted, allocate 
> larger buffer in low memory and use that to pass the parameters, then 
> deallocate it when the child returns.
> 
> The second option of course adds to the size and complexity of the code, 
> so I wonder if it's worth the hassle (I have it written, btw) and would 
> appreciate any comments before I decide which version to submit.  Thanks.

I think the overhead in option number two should be acceptable for 
applications that link in dosexec.c. The GNU standards also
suggest to avoid arbitrary limits on the length or number of *any*
data structure, including file names, lines, files, and symbols.


Please also try this recursive Makefile with the new version:

# Makefile
default:
	$(MAKE)
# end of Makefile


Here is what I get (SIGILL is not very nice):

[Snip]

make.exe[13]: Entering directory `e:/t'
e:/l/djgpp2/bin/make.exe
Exiting due to signal SIGILL
Invalid TSS at eip=000001ff, error=0004
eax=00010001 ebx=00030006 ecx=00000800 edx=000007bf esi=0000077c edi=000611c5
ebp=0001091c esp=00000760 cs=0007 ds=0007 es=0007 fs=0000 gs=0000 ss=0007
Call frame traceback EIPs:
  0x000001ff
General Protection Fault at eip=3e92; flags=3016
eax=00000300 ebx=00000021 ecx=00000000 edx=00065839 esi=00071600 edi=0006b238
ebp=0006b0e0 esp=00003844 cs=18 ds=33 es=3f7 fs=3cf gs=3ff ss=20 error=03ec
make.exe[12]: *** [default] Error 1
make.exe[12]: Leaving directory `e:/t'

[Snip]

- Raw text -