On 09/12/2016 11:08 AM, Michael Paquier wrote:
> On Fri, Sep 9, 2016 at 6:49 AM, Andres Freund <andres@anarazel.de> wrote:
>> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
>>>> I can't vouch for the windows stuff, and
>>>> the invocations indeed look vulnerable. I'm not sure if the fix actually
>>>> matters on windows, given . is the default for pretty much everything
>>>> there.
>>>
>>> Well, maybe it doesn't matter now but as I understand the fix is going
>>> to enter the next stable upstream perl, so it'll fail eventually. It'd
>>> be saner to just fix the thing completely so that we can forget about
>>> it.
>>
>> Yea, it'd need input from somebody on windows. Michael? What happens if
>> you put a line remove . from INC (like upthread) in the msvc stuff?
>
> I haven't tested that directly because I am not sure how to enforce
> INC when running the prove command through system(), and there is no
> point to use pop on @INC directly in vcregress.pl as that would just
> be ignored in the system() call. But to be short: this will blow up as
> @INC is part of the default per perl -V if one uses active perl. So it
> looks fair to me to append the local source directory as well to what
> is included. You can actually do that by just adding $dir to
> $ENV{PERL5LIB} in vcregress.pl and that would be fine.
I committed a fix for the unix Makefile, per Andres' original
suggestion, because this started to bother me. I tried reproducing this
on Windows by hacking Prove.pm to remove '.' from @INC, but I wasn't
able to make that to fail. So I didn't do anything about MSVC for now.
Let's fix vcregress.pl, when someone reports an actual problem on Windows.
- Heikki
