On 09/12/2016 11:08 AM, Michael Paquier wrote:
On Fri, Sep 9, 2016 at 6:49 AM, Andres Freund <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
