Mail Archives: djgpp-workers/1997/09/10/06:40:22
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.)
- Raw text -