From: Stephen Smith <ischis2@cox.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git List" <git@vger.kernel.org>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v3 4/4] wt-status.c: Set the committable flag in the collect phase.
Date: Sun, 23 Sep 2018 20:15:16 -0700 [thread overview]
Message-ID: <2295579.U4Xb9QnJqG@thunderbird> (raw)
In-Reply-To: xmqqworxufuv.fsf@gitster-ct.c.googlers.com
On Friday, September 7, 2018 3:31:55 PM MST Junio C Hamano wrote:
> For example, I noticed that both of the old
> callsites of wt_status_get_state() have free() of a few fiedls in
> the structure, and I kept the code as close to the original, but I
> suspect they should not be freed there in the functions in the
> "print" phase, but rather the caller of the "collect" and "print"
> should be made responsible for deciding when to dispose the entire
> wt_status (and wt_status_state as part of it). This illustration
> patch does not address that kind of details (yet).
I followed the call tree back to original callers run_status() and
cmd_status() in commit.c
This leads to a philosophical question. We want to move the state information
out of the print functions because it doesn't seem correct. For the case in
question this includes the calls to free() . By doing this we seem go have
traded one location that shouldn't be touching the state variables for
another.
I can see three solutions and could support any of the three:
1) Move the free calls to run_status() and cmd_status().
2) Move the calls calls to wt_status_print since that is the last function
from wt_status.c that is called befor the structure goes out of scope in
run_status() and cmd_status().
3) Add a new wt_collect*() function to free the variables. This would have an
advantage that the free calls could be grouped in on place and not done in to
functions. A second advantage is that the free calls would be located where
the pointers are initialized.
Personally I like solutions 1 and 3 over 2.
What do others think?
sps
next prev parent reply other threads:[~2018-09-24 3:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 0:53 [PATCH v3 0/4] wt-status.c: commitable flag Stephen P. Smith
2018-09-06 0:53 ` [PATCH v3 1/4] Move has_unmerged earlier in the file Stephen P. Smith
2018-09-06 0:53 ` [PATCH v3 2/4] wt-status: rename commitable to committable Stephen P. Smith
2018-09-07 21:38 ` Junio C Hamano
2018-09-06 0:53 ` [PATCH v3 3/4] t7501: add test of "commit --dry-run --short" Stephen P. Smith
2018-09-06 0:53 ` [PATCH v3 4/4] wt-status.c: Set the committable flag in the collect phase Stephen P. Smith
2018-09-07 22:01 ` Junio C Hamano
2018-09-07 22:31 ` Junio C Hamano
2018-09-28 4:49 ` [PATCH 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-28 4:49 ` [PATCH 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-28 13:55 ` Taylor Blau
2018-09-28 18:34 ` Junio C Hamano
2018-09-29 18:55 ` [PATCH v2 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-29 18:55 ` [PATCH v2 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-30 4:41 ` Eric Sunshine
2018-09-30 14:12 ` [PATCH v3 0/1] wt-status-state-cleanup Stephen P. Smith
2018-09-30 14:12 ` [PATCH v3 1/1] roll wt_status_state into wt_status and populate in the collect phase Stephen P. Smith
2018-09-30 4:40 ` [PATCH " Eric Sunshine
2018-09-07 23:55 ` [PATCH v3 4/4] wt-status.c: Set the committable flag " Stephen P. Smith
2018-09-11 17:22 ` Junio C Hamano
2018-09-24 3:15 ` Stephen Smith [this message]
2018-09-24 21:02 ` Junio C Hamano
2018-09-06 7:38 ` [PATCH v3 0/4] wt-status.c: commitable flag Ævar Arnfjörð Bjarmason
2018-09-06 16:06 ` Stephen & Linda Smith
2018-09-07 21:40 ` Junio C Hamano
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=2295579.U4Xb9QnJqG@thunderbird \
--to=ischis2@cox.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.com \
--cc=szeder.dev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.