Date: Wed, 13 Jun 2001 12:36:10 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: alex bodnaru cc: djgpp-workers AT delorie DOT com Subject: Re: printing to a device In-Reply-To: <3b27b278.56c.0@NewMail.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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?