This is the mail archive of the gcc-patches@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: [PATCH] Support %N$/*N$ style format arguments in GCC diagnostics


On Fri, May 20, 2005 at 01:22:24PM -0700, Zack Weinberg wrote:
> > I tried to make the requirements match POSIX *printf requirements.
> > pp_base_format_text works in 3 phases, first it scans the format string
> > and records the arguments, then, with optional help of a hook stores
> > the arguments into a union and finally prints them as it used to print them
> > before, only instead of va_arg directly it uses that union.
> 
> I'd like to draw your attention to the algorithm outlined in
> <http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02551.html>.  I think
> it's pretty close to the algorithm you implemented, but it doesn't
> need the union (at the cost of slight, IMO actively desirable,
> deviation from POSIX - you can't refer to the same argument twice with
> different format specifiers) and should be structurally simpler.

I don't see how it simplifies things, just instead of storing the va_arg
values you store strings and copy them around, both algorithms have
3 phases, 2 of them iterate over the format string and one iterates over
used argument numbers.
Plus the more limitations you impose the bigger chances are some translators
will not handle it correctly.
E.g. in the move strings around scheme, handling:
"this is a string %3$.*1$s and decl %2$D", 5, decl, "abcdefg"
is not possible (you would need to restrict that string max length and
string arguments are adjacent),
"shorter %2$.*1$s and longer %2$.8s strings", 4, "abcdefghijk"
would be hard.

> Also, it deals quite nicely with the %H/%J issue you brought up; in
> fact, it opens the way for us to resurrect C++'s old %+D notation and
> not have to pass decls twice in so many places.

This can be dealt with in either of the algorithms.  Just means
phase 1 and phase 2 are moved to a separate routine, e.g. that
pp_base_prepare_to_format and that using pp_prepare_to_format
will be mandatory before pp_format_text.  Perhaps if pp_prepare_to_format
is called with NULL locus, the special handling of initial %H, %N$H,
%J, %N$J would not be done.  But %+D is doable there just fine,
the hook will just set locus.

	Jakub


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