Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] xcoffread.c: remove include of partial-stab.h
Date: Mon, 01 Oct 2001 14:29:00 -0000	[thread overview]
Message-ID: <15288.57821.215096.623909@krustylu.cygnus.com> (raw)
In-Reply-To: <1011001210800.ZM19181@ocotillo.lan>

Kevin Buettner writes:
 > On Sep 30,  5:08pm, Elena Zannoni wrote:
 > 
 > > Turns out that xcoffread.c used only 2 of the many cases handled by
 > > the switch in partial-stab.h. In order to reuse the whole file, a lot
 > > of macros had to be defined to do nothing.
 > > 
 > > I tested this patch on an aix4.3 system.
 > > 
 > > I know this file has no official maintainer, but I'll wait a few days
 > > to check it in anyway.
 > 
 > I've looked this patch over.  I've verified that only two cases of
 > partial-stab.h were needed by xcoffread.c.  Also, it appears to me
 > that you've correctly integrated the two necessary cases into
 > xcoffread.c.

Thanks for looking this over.

 > 
 > My only concern about this patch is with the duplication of the two
 > cases in xcoffread.c.  These hunks of code are of substantial size and
 > it occurs to me that correct maintenance of this code may require
 > keeping the various copies in sync.  I'm wondering if it'd be possible
 > to turn these hunks of code into functions.  That way we might be able
 > to avoid duplicating (some of) this code in three different places.
 > 

Yes, that was the way I started thinking about this code too. But I
realized that it is probably better to completely decouple these
cases, so that a change to accomodate format A doesn't affect format B
or C.  I think this common base was the reason for the 'fear' of
change in this code. By making these independent, it will become
easier to clean the code up w/o having to worry about other platforms,
that may be hard to test on (I had to dig around quite a bit to find
an AIX machine).  I think the code can be simplified more this way
too, for instance we can get rid of the macro DBXREAD_ONLY, and a few
others.

 > Kevin


Elena


  reply	other threads:[~2001-10-01 14:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-30 14:01 Elena Zannoni
2001-10-01 13:11 ` Andrew Cagney
2001-10-01 14:08 ` Kevin Buettner
2001-10-01 14:29   ` Elena Zannoni [this message]
2001-10-01 15:26     ` Kevin Buettner
2001-10-01 15:42   ` Andrew Cagney
2001-10-01 19:40 ` Elena Zannoni

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=15288.57821.215096.623909@krustylu.cygnus.com \
    --to=ezannoni@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.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