Re: C99 "for (int ..." form on "master" (was: [PATCH v3 4/5] merge-ort: shuffle the computation and cleanup of potential collisions)

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

 



On Mon, Jul 25, 2022 at 5:04 AM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
>
> On Fri, Jul 01 2022, Ævar Arnfjörð Bjarmason wrote:
>
> > On Fri, Jul 01 2022, Elijah Newren via GitGitGadget wrote:
> > [...]
> >> @@ -3106,6 +3105,7 @@ static int detect_and_process_renames(struct merge_options *opt,
> >>  {
> >>      struct diff_queue_struct combined = { 0 };
> >>      struct rename_info *renames = &opt->priv->renames;
> >> +    struct strmap collisions[3];
> >>      int need_dir_renames, s, i, clean = 1;
> >>      unsigned detection_run = 0;
> >>
> >> @@ -3155,12 +3155,22 @@ static int detect_and_process_renames(struct merge_options *opt,
> >>      ALLOC_GROW(combined.queue,
> >>                 renames->pairs[1].nr + renames->pairs[2].nr,
> >>                 combined.alloc);
> >> +    for (int i = MERGE_SIDE1; i <= MERGE_SIDE2; i++) {
> >
> > The "int i" here will need to be pre-declared earlier, per: 6563706568b
> > (CodingGuidelines: give deadline for "for (int i = 0; ...", 2022-03-30)
> >
> > I also don't mind us just saying "we've waited enough". Junio?
>
> This case got fixed, but per the changed $subject others have snuck
> through.
>
> Since be733e12001 (Merge branch 'en/merge-tree', 2022-07-14) we've had
> these forms on "master", see 6debb7527b0 (merge-ort: store messages in a
> list, not in a single strbuf, 2022-06-18) and cb2607759e2 (merge-ort:
> store more specific conflict information, 2022-06-18).
>
> We could "fix" those, but per the above I think it's just as valid to
> just move up the deadline & say that 2.38.0 will have a hard dependency
> on this C99 feature...

Thanks for catching this and bringing it up; sorry for missing it earlier.

6563706568b says we should "revisit this *around* November 2022"
(emphasis added).  2.38 will be released in October 2022.  So, maybe
it's fine as-is.

But if others prefer these be fixed over moving up the deadline, I'll
go ahead and submit a patch.

I guess we just need a call.  Junio?




[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