From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: djgpp-workers AT delorie DOT com Date: Fri, 11 Apr 2003 15:51:28 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: %n$, *m$ and some other c99 support for doprnt.c In-reply-to: <3E91678A.7F3AC0D2@phekda.freeserve.co.uk> X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: <166043C1445@HRZ1.hrz.tu-darmstadt.de> X-MailScanner: Found to be clean 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 Hello. 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. ;) Martin Stromberg wrote: > > +struct IEEExp { > > + unsigned manl:32; > > + unsigned manh:32; > > + unsigned exp:15; > > + unsigned sign:1; > > +}; > > What is wrong with long_double_t from libc/ieee.h? Nothing. I have simply not noticed it. I will fix the issue. 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. > > +#define GET_ARG_INDEX() \ > > + /* \ > > + Check for %n$ argument specifiers. \ > > + If numbered argument conversion specifiers are used, table_index will \ > > + be set to the appropriate value. For unnumbered argument conversion \ > > + specifier this is a no action. \ > > + */ > > I suggest: "no action" -> "no-op". OK, I will fix it. 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. > > 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) > Also, why is it the number of the last argument? Isn't it a maximum number of > arguments? It is the number of the last argument passed to printf. AFAIK there is no limit to the amount of arguments passed to printf. To make the issue clear: printf(format_string, arg1, arg2, ........., argN); NL_ARGMAX == N. NL_ARGMAX is the number of the last argument in the list. > > If you send a diff with these things fixed, I think it should be committed to > > CVS. I can do that, if you'd like - perhaps next weeked (Easter weekend). > > Sorry, but I can't remember: Have you completed all the copyright forms for > > DJ? I will try to submit a fixed patch today or tomorrow. 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. Regards, Guerrero, Juan Manuel