Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA]: Remove unused header files.
Date: Tue, 06 Mar 2001 13:27:00 -0000	[thread overview]
Message-ID: <5mvgpm4mgx.fsf@jtc.redback.com> (raw)
In-Reply-To: <3AA2C971.D2432CEA@cygnus.com>

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> The decode_line_1() declaration (IMO) indicates a unclear separation
>> of interface and implementation.  (Again, IMO) a function declaration
>> should only be in one header.  Please share your thoughts, on this
>> specific case, and in general.  decode_line_1() is the first of many
>> functions that have multiple declarations.

Andrew> Only one? Just don't get me started on the number of extern
Andrew> declarations that appear in .c files! :-) Yes, I agree that
Andrew> function declarations should only appear once.

Is this one of the things your static analysis database is checks for
(And can you send me a pointer to it again)?  

When I was going through the code, I saw one comment describing how a
few functions were being declared locally so the header containing the
declarations would not have to be included.  This seems like a recipe
for disaster.  If the interface is ever changed, the programmer might
miss the local declaration when fixing up the callers.  And the compiler
won't complain because the usage within that function will match the
(local) declarations.  Bleh.

If it was my rule, function declarations should only appear once and 
should *never* occur in *.c files.

Andrew> As for the more general question of confused interfaces.  I
Andrew> think GDB's internal structure is facing major change
Andrew> (multi-arch).  Consequently I'm hopeing that that that that
Andrew> work will address many of those problems.  I suspect that, at
Andrew> this stage, you might want to put blinkers and just
Andrew> concentrate on the basic #include mess.  That, by its self, is
Andrew> pretty daunting.

Note I'm not trying to fix everything I come across, at least not in
the first pass.  For the most part, I am trying to categorize things 
so I know what's the most benefit for the least effort.

The side-effect of this is that I'll likely be raising a lot of issues
wrt inconsistancies.  I won't be offended if you tell me to punt on
any of them.

        --jtc

-- 
J.T. Conklin
RedBack Networks


  parent reply	other threads:[~2001-03-06 13:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-01 17:44 J.T. Conklin
2001-03-02  8:25 ` Andrew Cagney
2001-03-02 16:34   ` J.T. Conklin
2001-03-05  8:11     ` Andrew Cagney
2001-03-06 13:08       ` J.T. Conklin
2001-03-05  8:11 ` Andrew Cagney
2001-03-06 13:10   ` J.T. Conklin
2001-03-05  8:11 ` Andrew Cagney
2001-03-06 13:02   ` J.T. Conklin
2001-03-05  8:11 ` Andrew Cagney
2001-03-06 12:38   ` J.T. Conklin
2001-03-05  8:11 ` Andrew Cagney
2001-03-06 12:41   ` J.T. Conklin
2001-03-05  8:11 ` Andrew Cagney
2001-03-06  9:20   ` Fernando Nasser
2001-03-06 11:32     ` J.T. Conklin
2001-03-06 13:27   ` J.T. Conklin [this message]
2001-03-06 15:06     ` Andrew Cagney

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=5mvgpm4mgx.fsf@jtc.redback.com \
    --to=jtc@redback.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sourceware.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