Re: [PATCH v3 5/8] evolve: Add the change-table structure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]);
>>  }
>>



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux