From: Doug Evans <xdje42@gmail.com>
To: Stan Shebs <stanshebs@earthlink.net>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Delete struct inferior_suspend_state
Date: Sat, 09 Aug 2014 20:53:00 -0000 [thread overview]
Message-ID: <CAP9bCMTDnvfFTb4XGD5nnXfqZRn6hyEWWc6-SAOt1rd6xprFYw@mail.gmail.com> (raw)
In-Reply-To: <53E55C6F.80901@earthlink.net>
On Fri, Aug 8, 2014 at 4:25 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> On 7/31/14, 12:10 PM, Doug Evans wrote:
>> Hi.
>>
>> I happened across some #if 0's in the code and thought that odd.
>>
>> I found the relevant thread here:
>>
>> https://sourceware.org/ml/gdb-patches/2012-06/msg00370.html
>>
>> Any desire to continue to keep this, or can we delete it?
>> [I don't have a strong preference, but it feels like it's time.]
>
> I was sure we had set a policy to delete code instead of doing #if 0,
> but I can't find anything in writing that says so.
>
> In any case, retaining dead code seems pointless when version control
> systems make it easy to find again.
... assuming you know it's there to look for.
In this particular case, the intent is to leave documentation on how
it's intended a particular bit of code be extended (in part because C
doesn't allow empty structs so a compromise is made).
Would anyone faced with a particular situation such as this go back
through the repo looking just in case such documentation was there and
then got deleted? Perhaps, but I'd totally understand if someone
ended up putting time into it only to be told a decision has been made
to do it differently and being disappointed that the documentation of
that decision was in deleted text recorded only in the repo. [It may
turn out that the "decision" is not an absolute one of course, but
it's still documentation we're talking about, not (dead) code.]
Maybe in addition to a rule to not use #if 0, we also need a rule to
not document how it's intended code be extended (at least not as the
code).
I can see a case made for either side of this, depending on the situation.
prev parent reply other threads:[~2014-08-09 20:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 19:30 Doug Evans
2014-07-31 19:46 ` Jan Kratochvil
2014-07-31 19:54 ` Doug Evans
2014-07-31 20:33 ` Joel Brobecker
2014-07-31 20:42 ` Doug Evans
2014-07-31 20:58 ` Joel Brobecker
2014-07-31 21:11 ` Doug Evans
2014-07-31 21:53 ` Joel Brobecker
2014-08-01 2:04 ` Doug Evans
2014-08-08 23:25 ` Stan Shebs
2014-08-09 20:53 ` Doug Evans [this message]
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=CAP9bCMTDnvfFTb4XGD5nnXfqZRn6hyEWWc6-SAOt1rd6xprFYw@mail.gmail.com \
--to=xdje42@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=stanshebs@earthlink.net \
/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