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@xxxxxxxxx> wrote: > > Stefan Xenos <sxenos@xxxxxxxxxx> 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@xxxxxx> wrote: > >> > >> Hi Junio, > >> > >> On Mon, 28 Jan 2019, Johannes Schindelin wrote: > >> > >> > On Sun, 27 Jan 2019, sxenos@xxxxxxxxxx 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]); > >> } > >>
