Re: [PATCH v4 0/5] urlmatch: allow wildcard-based matches

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

 



On Mon, Jan 30, 2017 at 02:52:00PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
> > Patrick Steinhardt <patrick.steinhardt@xxxxxxxx> writes:
> >
> >>  - I realized that with my patches, "ranking" of URLs was broken.
> >>    Previously, we've always taken the longest matching URL. As
> >>    previously, only the user and path could actually differ, only
> >>    these two components were used for the comparison. I've
> >>    changed this now to also include the host part so that URLs
> >>    with a longer host will take precedence. This resulted in a
> >>    the patch 4.
> >
> > Good thinking.  I was wondering about this, too.
> >
> > Thanks.  Will read it through and replace.
> 
> Ugh.  When applied on top of 4e59582ff7 ("Seventh batch for 2.12",
> 2017-01-23), Git fails its self-test in t5551 #31 (I do not run with
> EXPENSIVE so some tests liks #30 are skipped, if it matters).
> 

Thanks for letting me know. I didn't have any errors on my other
machine, but was actually able to reproduce test failures on this
one.

Embarassingly, I forgot to zero-initialize the `struct
urlmatch_item`, leading to undefined behavior when searching for
configuration keys without a dot inside. This is the case for
nearly all keys, except for example the ones with a URL inside.

Will re-send a fixed version.

Attachment: signature.asc
Description: PGP signature


[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]