Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] dwarf2read.c: complain() -> complaint()
Date: Wed, 11 Dec 2002 10:47:00 -0000	[thread overview]
Message-ID: <vt23cp48mh8.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <3DF6129C.9000700@redhat.com>

Andrew Cagney <ac131313@redhat.com> writes:

> > In a recently submitted patch, I added a new complaint to dwarf2read.c
> > using the old (deprecated) interface.  Andrew asked me to use the new
> > interface.  I've generated a patch for dwarf2read.c which converts all
> > calls to complain() to complaint().
> > I've written a script to do this transformation.  It finds all of the
> > deprecated_complaint structs and counts the uses of these
> > structs. (Surprisingly, some were unused!)  For cases where there's
> > more than
> > one occurrence, it creates a new function as suggested in
> > complaints.h.  For the rest, it performs the obvious transformation.
> > The script also uses GNU indent to perform localized reindentations
> > of
> > the affected text.
> > If this patch is accepted (and this approach is deemed acceptable),
> > I'll
> > generate patches for the other files which still use complain().
> 
> Definitly fine with the theory.  Two reservations (really just one).
> 
> - how is the result with -Wformat?  The reason behind switching from
> complain() to complaint was to get the parameters checked and hence
> find some nasty address printing bugs.
> 
> - I suspect it will need a visual audit to check for any cases of:
> 	"%08lx", (long) core_addr_variable
> 
> Looking through this specific patch, though, turned up no cases where
> this occured. So you must have that those problems covered.
> 
> Symtab maintainers?

It looks fine to me.

I was uncomfortable with the idea of having to create wrapper
functions at first --- the idea being that each occurrence of a
complaint string is its own independent complaint --- but it seems
like it'll do the right thing by default more often than making people
create complaint structures.  So I'll go with that.


  parent reply	other threads:[~2002-12-11 18:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-09 15:42 Kevin Buettner
2002-12-10  8:32 ` Andrew Cagney
2002-12-10  9:03   ` Kevin Buettner
2002-12-11 10:47   ` Jim Blandy [this message]
2002-12-11 12:23     ` Andrew Cagney
2002-12-11 14:15       ` Jim Blandy
2002-12-11 14:34         ` Andrew Cagney
2002-12-11 13:02 ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vt23cp48mh8.fsf@zenia.red-bean.com \
    --to=jimb@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox