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

["Zack Weinberg" <zack at codesourcery dot com>]

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

> Zack Weinberg wrote:
>> <ishikawa@duron.erephon> writes:
>> [Incidentally, could you please fix your Reply-To: and/or From: line
>> so that we don't have to edit the message headers when we reply to
>> you? Thanks in advance.]
>>
> Sorry about the mail setup problem.
> I will try to see what I can do.

This message has the problem fixed.  Thanks.

> (There were things I didn't kwow like the capital letter version of
> fucnitions in ctype.h. Are there GCC-specific coding style documents
> somewhere?).

There is, unfortunately, no complete document.  There are three
partial documents: README.Portability and doc/sourcebuild.texi in the
gcc subdirectory, and http://gcc.gnu.org/codingconventions.html on the
webpage.

>>  - Make sure all lines are wordwrapped to 80 columns.
>
> (I am not sure whether this referes to the original coding style or
>   maybe the mail handler wrapping the code at unwanted positions?)

The original coding style.

>>    instead do something similar to error_recursion ().
>
> I did this, but I guess I can obtain nicer output
> for contacting GCC support mailing list, etc. by calling
> error_recusion()(?).

The message delivered by error_recursion is not quite right for this
situation.  I suggest you generalize error_recursion into, let's call
it internal_diagnostics_error():

void
internal_diagnostics_error (diagnostic_context *context,
                           const char *msgid, ...)
{
  va_list ap;
  if (context->lock < 3)
    pp_flush (context->printer);

  va_start (ap);
  fprintf (stderr, _(diagnostic_kind_text[DK_ICE]));
  vfprintf (stderr, _(msgid), ap);
  putc ('\n', stderr);
  va_end (ap);

  fprintf (stderr, _(bug_report_request), bug_report_url);
  exit (FATAL_EXIT_CODE);
}

Then error_recursion() and your function can just call
internal_diagnostics_error() with the proper arguments.

> I have been away from my PC for more than a week due to a business
> trip, but when is exactly the 3.4 release time frame?

See http://gcc.gnu.org/develop.html for the policy outline.  We are in
stage 3 of the 3.4 development cycle.  Dates have not been set for the
creation of the 3.4 branch and the final release; January 15 is the
earliest that the branch would be created, and I expect that it will
be later.  (We still have lots of bugs to fix.  Once we get through
this patch, your help fixing bugs would be greatly appreciated.)

zw