This is the mail archive of the 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 in diagnostics.c

Chiaki <> 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 on the

>>  - 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():

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

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


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