Message-ID:	<34168D9A.73D0@bo.dada.it>
Date:	Wed, 10 Sep 1997 14:07:54 +0200
From:	Diego Zuccato <dz AT bo DOT dada DOT it>
Organization:	CyberSpace Software Labs BBS
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: Transfer buffer (Was: Re: fread slowstart)
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 970910133035 DOT 10042A-100000 AT is>

Eli Zaretskii wrote:

> 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.
Well, libc code is something that we can (and should, IMHO) modify to
handle this.
It's not possible that a tb is altered out of libc contol, right ?
There isn't user-code involved. If the 'interface' isn't modified, the
code can be changed.
I don't remember libc functions that assume that tb isn't altered.
Them all should consider it a 'fire&forget' bucket, where data isn't
constant.

> 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.
It can happen only when executing child programs, right ?
Why not to save tb contents (if important...) and recall them after the
call?

> 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.)
Well. 16Kb less in DOS memory is worst than 16Kb in flat (over 1Mb)
memory, since if needed we can swap out flat memory but not DOS memory.
But, after all, is it really asserted somewhere that tb is unaltered
after executing a child program ?
I don't like wasting memory (often I use bitfields instead of char
flags), but if it could be useful (eg to recursively spawn more child
processes) I prefer 'wasting' the cheapest resource. DOS memory is quite
'expensive' (it's relly limited), while flat memory is quite cheap
(there's much more).

- Raw text -