All of lore.kernel.org
 help / color / mirror / Atom feed
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








  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.