From: Stefan Xenos <sxenos@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git <git@vger.kernel.org>
Subject: Re: [PATCH v3 5/8] evolve: Add the change-table structure
Date: Tue, 29 Jan 2019 10:09:42 -0800 [thread overview]
Message-ID: <CAPL8ZiupbKuZMAymW8je9UJ61Tm5aoDcS1srQTf=y9iQEuPFoA@mail.gmail.com> (raw)
In-Reply-To: <xmqqef8v8hqp.fsf@gitster-ct.c.googlers.com>
Works with me. I'll resubmit without the double casting next chance I
have to work on it. My long-term plan for that struct was to use the
memory pool for all allocations anyway. I think that should let me
implement it without moving objects around, which will make their
addresses stable. That should let me use pointers for everything,
without the ints - so I probably won't need the union.
On Tue, Jan 29, 2019 at 10:02 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Xenos <sxenos@google.com> writes:
>
> > Sorry, folks. I normally can't do any open source work on weekdays.
> > That also includes writing responses on the mailing list, so there
> > will normally be a week or two lag for me to iterate on this sort of
> > thing.
> >
> > Feel free to either include this fix or revert my patch if there's a
> > problem with it - just let me know what you selected. I'll roll with
> > it and either resubmit with the requested changes or submit the
> > requested changes as follow-ups.
>
> I think double casting Dscho did was not his ideal "fix" but he did
> it as a mere workaround to force the 'pu' branch to compile. And I
> also agree with him that the double casting workaround is too ugly
> to live, compared to a union he suggests. So I'd rather kick the
> branch out of 'pu' for now.
>
> Thanks, both.
>
> >
> > - Stefan
> >
> > On Mon, Jan 28, 2019 at 3:08 PM Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >>
> >> Hi Junio,
> >>
> >> On Mon, 28 Jan 2019, Johannes Schindelin wrote:
> >>
> >> > On Sun, 27 Jan 2019, sxenos@google.com wrote:
> >> >
> >> > > + new_item->util = (void*)index;
> >> >
> >> > This is not good. You are using a `long` here. The 80s called and want
> >> > their now-obsolete data types back.
> >> >
> >> > If you want a data type that can take an integer but also a pointer, use
> >> > `intptr_t` instead.
> >> >
> >> > But even that is not good practice. What you really want here is to use a
> >> > union of the data types that you want to store in that `util` field.
> >> >
> >> > This is not merely academic, your code causes compile errors on Windows:
> >> >
> >> > https://dev.azure.com/gitgitgadget/git/_build/results?buildId=400&view=logs&jobId=fd490c07-0b22-5182-fac9-6d67fe1e939b&taskId=ce91d5d6-0c55-50f5-8ab9-6695c03ab102&lineStart=430&lineEnd=440&colStart=1&colEnd=1
> >>
> >> Since Stefan did not grace us with an answer, Junio, could I ask you to
> >> squash this in (which is by no means a satisfactory fix, but it is a
> >> stopgap to get `pu` building again)?
> >>
> >> -- snipsnap --
> >> diff --git a/change-table.c b/change-table.c
> >> index 2e0d935de846..197ce2783532 100644
> >> --- a/change-table.c
> >> +++ b/change-table.c
> >> @@ -103,7 +103,7 @@ void change_table_add(struct change_table *to_modify, const char *refname,
> >> new_head->hidden = starts_with(refname, "refs/hiddenmetas/");
> >>
> >> new_item = string_list_insert(&to_modify->refname_to_change_head, refname);
> >> - new_item->util = (void*)index;
> >> + new_item->util = (void *)(intptr_t)index;
> >> // Use pointers to the copy of the string we're retaining locally
> >> refname = new_item->string;
> >>
> >> @@ -201,6 +201,6 @@ struct change_head* get_change_head(struct change_table *heads,
> >> return NULL;
> >> }
> >>
> >> - index = (long)item->util;
> >> + index = (long)(intptr_t)item->util;
> >> return &(heads->heads.array[index]);
> >> }
> >>
next prev parent reply other threads:[~2019-01-29 18:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-27 19:44 [PATCH v3 1/8] technical doc: add a design doc for the evolve command sxenos
2019-01-27 19:44 ` [PATCH v3 2/8] sha1-array: Implement oid_array_readonly_contains sxenos
2019-01-28 2:05 ` Junio C Hamano
2019-01-27 19:44 ` [PATCH v3 3/8] ref-filter: Add the metas namespace to ref-filter sxenos
2019-01-27 19:44 ` [PATCH v3 4/8] evolve: Add support for parsing metacommits sxenos
2019-01-28 2:05 ` Junio C Hamano
2019-01-27 19:44 ` [PATCH v3 5/8] evolve: Add the change-table structure sxenos
2019-01-28 8:01 ` Johannes Schindelin
2019-01-28 23:08 ` Johannes Schindelin
2019-01-28 23:24 ` Stefan Xenos
2019-01-29 18:02 ` Junio C Hamano
2019-01-29 18:09 ` Stefan Xenos [this message]
2019-01-27 19:44 ` [PATCH v3 6/8] evolve: Add support for writing metacommits sxenos
2019-01-27 19:44 ` [PATCH v3 7/8] evolve: Implement the git change command sxenos
2019-01-27 19:44 ` [PATCH v3 8/8] evolve: Add the git change list command sxenos
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPL8ZiupbKuZMAymW8je9UJ61Tm5aoDcS1srQTf=y9iQEuPFoA@mail.gmail.com' \
--to=sxenos@google.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).