Mail Archives: djgpp-workers/2003/04/11/10:09:24
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
- Raw text -