Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E971C20.2BBE219@phekda.freeserve.co.uk> Date: Fri, 11 Apr 2003 20:48:48 +0100 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: %n$, *m$ and some other c99 support for doprnt.c References: <166043C1445 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Juan Manuel Guerrero wrote: > > Richard Dawe wrote: > > Maybe his could be done as a static inline function instead? (I have a > > personal preference of inline functions over macros (where possible), so > > feel free to ignore me.) > > Martin Stromberg wrote: > > > +#define GET_STAR_ARG_NUMBER() \ > > > > Long macros deleted. > > > > Why macros? I don't mind (it's your code), but isn't it better (easier > > to read and maintain) to make them functions? > > Well, AFAIK macros are simply faster than inlines so I prefer them over > inlines, but by popular demand I will convert the biggest ones to inline > functions. ;) "inline" is a suggestion to the compiler. So inline functions may not be inlined. [snip] > Richard Dawe wrote: > > > Concerning A,a conversion specifier. > > > Because I can not distinguish between float, double and long double args > > > passed to _doprnt(), I have assumed a default precision of 15 hex digits > > > in the fractional part of the mantissa. This means, if the user does not > > > specify a precision, always the full 60 binary digits will be converted > > > to hex digits and printed no matter if the passed argument is really a > > > long double or not. This is different from the way Linux behaves. > > > They seems to be capable to identify floats and then printing only the > > > 5 or 6 hex digits of the float mantissa if no precision is given by the > > > user. > > > > _doprnt does not distinguish between double and long double, because it > > passes values as long doubles to cvtl. But it could distinguish between > > double and long double. We know when we have a double and when we have > > a long double, because of the conversion qualifiers - e.g.: %e vs. %Le. > > I will take a look at this. Perhaps this could be fixed later in another patch. It would be quite a big change, I think. There are already a lot of changes in this patch! [snip] > If the comments I have added are more confusing than enlighting, please > let me know so I can remove them. I know that my english skills are limited > and I will certainly not be offended by such a request. > IMHO, people reading the code should not be confused by the comments but > I need to know if the comments are confusing. I found the comments to be fine, apart from the small things I have pointed out. They certainly helped me understand the code. > > > Index: djgpp/src/libc/ansi/stdio/printf.txh > > > =================================================================== > > > RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/printf.txh,v > > > retrieving revision 1.8 > > > diff -u -r1.8 printf.txh > > > --- djgpp/src/libc/ansi/stdio/printf.txh 29 Jan 2003 12:28:44 -0000 1.8 > > > +++ djgpp/src/libc/ansi/stdio/printf.txh 9 Apr 2003 06:42:50 -0000 > > > @@ -13,8 +13,24 @@ > > > Sends formatted output from the arguments (@dots{}) to @code{stdout}. > > > > > The format string contains regular characters to print, as well as > > > -conversion specifiers, which begin with a percent symbol. Each > > > -conversion speficier contains the following fields: > > > +conversion specifiers, which begin with a percent symbol. Conversions > > > +can be applied to the nth argument after the format string in the argument > > > +list, rather than to the next unused argument. In this case, the conversion > > > +specifier character @code{%} is replaced by the sequence @code{"%n$"}, where > > > +@code{n} is a decimal integer in the range [@code{1}, @code{NL_ARGMAX}], > > > +giving the position of the argument in the argument list. @code{NL_ARGMAX} > > > +is the number of the last argument in the argument list. > > [snip] > > > > Where is NL_ARGMAX defined? I can't see it defined in the headers in CVS. > > It doesn't seem to be used in the code. > > NL_ARGMAX is defined nowhere and do not need to be defined somewhere. > NL_ARGMAX is simply a symbolic name for the last argument passed to > printf(). I have taken this name from the standard. This has not been very > wise. I will replace it by the "number (or index) of the last argument" > or something similar. (Suggestions are welcome) I think talk of NL_ARGMAX will confuse users. I think you should replace it, as you suggest. "number of the last argument" sounds fine to me. [snip] > I have never signed any copyrights form for DJ. I have > always assumed that if I submit a patch I am atomatically > giving the copyrights to him. I assume he will clarify the issue > if needed. You may want to ask DJ directly. I don't know, if he will read this. I had to sign a copyright disclaimer, once I stated making major changes: more than a few lines IIRC - the /dev/zero support. My (ex-)employer also had to sign a copyright disclaimer. Thanks, bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]