Date: Sat, 12 Apr 2003 11:59:21 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: st001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De Message-Id: <9003-Sat12Apr2003115920+0300-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <3E8B4CC9.E21C27CF@hrz1.hrz.tu-darmstadt.de> (message from Juan Manuel Guerrero on Wed, 02 Apr 2003 22:49:13 +0200) Subject: Re: %n$, *m$ and some other c99 support for doprnt.c References: <3E8B4CC9 DOT E21C27CF AT hrz1 DOT hrz DOT tu-darmstadt DOT de> 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 > Date: Wed, 02 Apr 2003 22:49:13 +0200 > From: Juan Manuel Guerrero > > This is a patch to implement %n$, *m$ and some other c99 support for > _doprnt.c. Thanks a lot, and sorry for such a long delay before I could read the code (I can hardly find time these days to review any non-trivial changes). > To implement %n$ and *m$ support the functions __args_amount and > __load_arg_array have been added. To implement this funtionality the > format string is parsed three times. First the amount of distinct > arguments to be retired from stack is determinated by parsing the > string for the first time. After knowing the amount, an array of > unions is allocated and the arguments are retired from stack and > stored in the array. When the format string is parsed for the last > time to print the arguments, instead of accesing the stack, the > array is accesed. I have reservations about this design. Do we really need to allocate a separate array and copy the arguments there? What's wrong with accessing the original stack using the va_* macros? Is it so much slower than parsing the format spec 3 times? If the speed of va_* macros is a big issue (I'd like to see measurements to be convinced), we could still scan the format spec once and build an array of offsets into the stack to find each argument in O(1) (i.e. constant) time, can't we? But even if we do need to allocate an array, I'd prefer it to be allocated off the stack, not the heap, to keep at the absolute minimum the number of library functions that call malloc internally. To make sure we don't smash the stack when some terribly long arg list is used, we could use the `stackavail' function to see how much stack space is available, and fail the call to _doprint if there's not enough space to copy the arguments. There are several typos in the comments and in the *.txh files, so I'd suggest to run a speller on them. (Emacs has a command to spell-check only comments and strings in code, that could help you.) In particular, "determinate" should be "determine", and there's at least one place where my eye caught a "paded" (which should be "padded"). Thanks again for working on this.