Date:	Thu, 11 Sep 1997 09:06:18 +1100
From:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject:	Re: Transfer buffer (Was: Re: fread slowstart)
In-reply-to:	<Pine.SUN.3.91.970910165039.10485B-100000@is>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
	dz AT bo DOT dada DOT it
Message-id:	<199709112027.IAA03785@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization:	Tait Electronics Limited
MIME-version:	1.0
References:	<34168D9A DOT 73D0 AT bo DOT dada DOT it>
Comments:	Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>

On 10 Sep 97 at 16:54, Eli Zaretskii wrote:

> 
> On Wed, 10 Sep 1997, Diego Zuccato wrote:
> 
> > It's not possible that a tb is altered out of libc contol, right ?
> 
> Wrong.  Application code is free to use the transfer buffer also.

But I beleive you said earlier that the tb can't be expected to 
remain intact across library calls.  Any application that uses the tb 
and expects it to remain constant across a lib call *DESERVES* to 
crash and burn. IMHO, this goes for library functions as well. I 
myself have made heavy use of the tb. Heck, the stubify speedup was 
my idea and that's the only thing I know of in all of the djgpp 
source that relies the the tb contents, but thats only between a dos 
read and write, otherwise, I NEVER make any assumptions about the tb 
contents.


> 
> > I don't remember libc functions that assume that tb isn't altered.
> 
> I don't think any of them do, right now.  But this doesn't change
> anything, because having the contents of tb change under your feet
> is IMHO a Bad Thing.  It requires the library maintainer to be
> acutely aware at all times that such a possibility exists, and that
> ain't easy.
> 

It's a TRANSFER BUFFER.  Isn't a tb, by definition, volatile and not 
to be trusted?  IMHO, the only time the tb contents are reliable 
after a call is when that call FILLED the tb.

Ok, I can think of one situation where the programmer might rely on 
the contents of the tb: as an optimisation when making multiple dos 
calles with the same data, but different register contents (eg 
writing to two files at once).  However, this is one of those 
situations where you do this at your own risk, ie know what you're 
doing.

For the sake of efficiency, wouldn't it be better to use the single 
tb (I rather like the idea, despite my earlier posting) and document 
the fact the spawn*, exec* (?? doesn't that kill the current 
program?) and system are very likely to totaly corrupt the tb 
contents? Anyway, to my knowledge, the sole contents of the tb when 
making the exec call is the program path, it's command line and a few 
other parameters to dos.  These are not something you would normally 
want after the call anyway.

Bill
--
Leave others their otherness.

- Raw text -