Re: Support for %d$c format specifier

[Ishikawa <ishikawa at yk dot rim dot or dot jp>]

Bruce Korb wrote:
> 
> > My plan is
> >  - (1) first to incorporate the C++, and C extension into the positional
> >        paramter handling framework by extending the
> >        protocol between the decoder and diagnostic.c.
> >
> >        This is necesary for the positional parameter handling to
> >        be usable.
> 
> I confess I don't read everything on gcc/gcc-patches, so perhaps
> I missed something.  Is there a reason not to use a pre-existing
> library for this stuff?  e.g.:
> 
>   http://savannah.nongnu.org/projects/libsnprintfv/
> 
> especially given:
> 
> > However, we have a limited man-power obvioulsy.

Hmm, I never expected that the support for positional
parameter generates so many posts, and it is rather difficult to keep
up.

Thank you for pointing out libsnprintfv exists.
As for libsnprintfv,  
I suspect the problem is that
GCC's diagnostic.c has some interwinding relationship with
the particularity of the way the functions in it are used in the
rest of GCC suite of programs.
Before we get to the bottom of the
formatting in output_format(), we
see many wrappers that setup or extract the
environmental info such as the line number of
the source file, source file name itself, etc..
So we must fit the libsnprintfv into diagnostic.c, and
then we need to incorporate the extended format specifier support.
(GCC's diagnostic.c already has it and it is used by g++ and objc front
end. It only doesn't work with positional parameter support yet, which I
am trying to fix.)

Fitting may not be that hard, but
we need the extended format specifier support right away.
(c++ and and obj-c frontend uses it as of now.)

The web page says,

>The only tile missing to the 1.0 release is dynamic loading of custom
>specifiers.

How is the tile comping?  

Oh, I forgot to mention. Another thing is that
the output_format() only supports a subset of C's format specifier
since it is used only for compiler diagnostics. (For example,
float/double printing is not supported.).
So in a sense, it can be a lot simpler than complete snprintf(), but
the dynamically loaded decoder support complicates things very much
indeed.

Incidently, I believe, though, glibc has an implementation of
s{n}printf() routines.
Is there any reason for independent development ?



-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */