This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support for %d$c format specifier


Ishikawa wrote:

> 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.

I don't know about that.  I know that it implements the numbered
arguments, extended arguments (user defined formatting) and argument
vectors (pretty unique to the library).

> 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.

All designed into the thing and written for the purpose of (eventually)
being incorporated into libiberty.

> Fitting may not be that hard, but
> we need the extended format specifier support right away.

It ought to be pretty easy.  It has an "asprintf" interface that
allocates the string, too.

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

I don't know precisely what Paolo is referring to.  Paolo?  :-)

> 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.).

Yeah, the library ought to get hacked to allow the float stuff to be
compiled out.  As it stands, it does require libm, but it ought
to be a simple configury thing to fix it.

> So in a sense, it can be a lot simpler than complete snprintf(), but
> the dynamically loaded decoder support complicates things very much
> indeed.

Simpler to execute, harder to code - if the complete library is already done.

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

1.  numbered args were incomplete at the time
2.  I needed argument vectors & glibc doesn't have it
3.  asprintf has proved to be very handy
4.  It was written to be included with libiberty.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]