Message-ID: <34168D9A.73D0@bo.dada.it> Date: Wed, 10 Sep 1997 14:07:54 +0200 From: Diego Zuccato Organization: CyberSpace Software Labs BBS MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Transfer buffer (Was: Re: fread slowstart) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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).