Mail Archives: djgpp-workers/2003/04/11/15:49:35
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/ ]
- Raw text -