www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/06/13/05:39:50

Date: Wed, 13 Jun 2001 12:36:10 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: alex bodnaru <alexbodn AT NewMail DOT Net>
cc: djgpp-workers AT delorie DOT com
Subject: Re: printing to a device
In-Reply-To: <3b27b278.56c.0@NewMail.Net>
Message-ID: <Pine.SUN.3.91.1010613122721.16126d-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Wed, 13 Jun 2001, alex bodnaru wrote:

> all the modification is making a function responsible
> for the real text formatting, from the part of _doprnt
> that comes right after the FILE flag
> operations. i have named this new function _doprnt_low,
> and it is able to generate formatted text using any data
> structure that the provided
> print_putc routine might manipulate. _doprnt_low should
> be called by _doprnt at the same point it's code has
> been cut off _doprnt.

Since you only change _doprnt, this feature will only work for output 
that goes through printf and fprintf.  If the program uses other 
functions, like putc, puts, fwrite, or anything else, the output will not 
get to the correct destination.  This is a serious misfeature, I think.

Or am I missing something?

> here is why didn't i choose the virtual file system services:
> 
> the use i make of this enhancement is for a data structure
> that simulates stdio operations on a memory string. the
> appropriate fputc function will
> trigger automatic string reallocation, or will conversely
> fail output upon reaching the buffer capacity limit (think
> of snprintf).

These issues should be resolved by the person who writes the FSEXT hook.  
If string reallocation is not appropriate, then the hook should be 
written such that it doesn't reallocate.  In other words, since the hook 
function is under your control, you can do there whatever you want, 
exactly as you do with any other implementation of this feature.  I don't 
see why you think FSEXT cannot solve these problems as well as you did.

> all this is done with the help of 5 long integers and
> a pointer in a strbuf struct. should i use the virtual
> file system, the strbuf would make the
> pseudo file descriptor layer, and will be buffered again
> through a bigger FILE structure, in case i make use of
> any *printf functionality.

No, this is a misunderstanding: FSEXT does not introduce any additional 
buffering of any additional FILE objects.

> moreover, string operations are usually very abundant,
> and are not taking into consideration such system limits
> like maximum file handles, that will be overrun very
> fast, in deficit of the real file/port/socket usage.

You have 255 file handles.  Isn't that enough for your application?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019