Date: Thu, 11 Sep 1997 09:06:18 +1100 From: Bill Currie Subject: Re: Transfer buffer (Was: Re: fread slowstart) In-reply-to: To: Eli Zaretskii , 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <34168D9A DOT 73D0 AT bo DOT dada DOT it> Comments: Authenticated sender is Precedence: bulk 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.