Date: Wed, 10 Sep 1997 13:39:14 +0300 (IDT) From: Eli Zaretskii To: Diego Zuccato cc: djgpp-workers AT delorie DOT com Subject: Re: Transfer buffer (Was: Re: fread slowstart) In-Reply-To: <34166E20.543C@bo.dada.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 10 Sep 1997, Diego Zuccato wrote: > Why ? Why should I SUSPECT that a tb in DOS memory is used ? > I pass to write() a buffer that can be everywhere in memory. Then > write() itself handles tb. I hope the user have NEVER to worry about > even the EXISTENCE of a tb in DOS memory. The passed buffer shouldn't be > altered without notice. tb is something 'for internal use only'. :-) We are talking about the library internals here, remember? This thread was originated by discussions about what library functions should or should not do. As far as the library is concerned, the transfer buffer *is* something to worry about, since it exists primarily for the libc functions. > missing something, write() calls multiple times DOS services, filling > multiple times the tb with different data. So the tb is altered more > than once with a single call... No, look at the lowest level, at the level of the call to __dpmi_int. You usually won't suspect that between the call to __dpmi_int and until it returns the contents of the transfer buffer is changed. What you suggest will break this when __dpmi_int is called to run a child program. > > Of course, you could save and restore the contents of tb, but that's > > not how it works now. > It could be changed, if needed, right ? :-) That should need no more > than 20 lines of code, or 2 function calls (saveTB and restoreTB). Anything can be done, given enough motivation and free time, and provided you aren't the one who gets flamed when users discover how much KBytes their programs get bloated from version to version. (Hint: the amount of code to save/restore the tb is not everything, you also need those 16KB to save it.)