Support for %d$c format specifier in diagnostics.c

[Zack Weinberg]

Ishikawa <ishikawa@yk.rim.or.jp> writes:

> Zack Weinberg wrote:
>> 
>> Ishikawa <ishikawa@yk.rim.or.jp> writes:
>> 
>> >> LC_MESSAGES=C should disable translation without any other effect.
>> >> (Not all systems support this variable, however.)
>> >
>> > Thank you for the info. Hmm, I am not sure which system supports
>> > LC_MESSAGES and which doesn't.
>> If you are interested in I18N projects, another worthwhile improvement
>> would be to add support for %n$s notation to diagnostic.c.  See
>> <http://www.opengroup.org/onlinepubs/007904975/functions/printf.html> for
>> details of how this is supposed to work.
>> 
>> I'll be happy to answer questions as you have them.
>
> As per Zack's suggestion, I am working on the initial cut of
> the support of %n$s notation in diagnostic.c
> (This is not strictly I18N/L10N stuff, though.)
>
> Anyway, here is an overview of what I am coding and
> comment/feedback welcome.

You've got the right idea.  Two comments:

> (UNLESS one such reference to a format specifier in the form of
> %n$c is done, we won't have the overhead of the array construction.)

Diagnostic message output doesn't have to be hyper-efficient.  If it
simplifies the code to make the array always, do that.

> Now, I am not entirely sure of the usage
> rule of %n$c format specifier.
>
> It seems to me ONCE we use the %n$ construct,
> we probably need to use this format from this point on always.
> (Or we need to use this form for ALL the format specifiers.)

I believe SUS says somewhere that you can use this notation for all or
none, but not some.  Even if it doesn't, I think that's an acceptable
limitation for GCC's implementation.

> OK	    %1$d %3$c %2$s %6$d %5$s %4$c
>
> OK	    %d %s %c %6$d %5$s %4$c
>
> ambiguous   %d %s %c %6$d %s %4$c
>             1  2  3   4   5  6

So, yes, don't permit your third example, and I wouldn't permit the
second either.

zw