Front page | perl.perl5.porters |
Postings from October 2012
On Wed, Oct 10, 2012 at 3:09 AM, Steffen Mueller <smueller@cpan.org> wrote:
>
> I've since come around to thinking that it's perfectly ok for these tests to
> fail. Exposing "we didn't compile in taint support" to Perl is very messy.
> Instead, things explicitly checking ${^TAINT} (how perl exposes -t/-T
> settings to Perl) should always get 0 under NO_TAINT_SUPPORT. If there's
> tests like t/run/switcht.t which EXPLICITLY test for ${^TAINT} being
> something else when run under -t, they must fail. Let's consider this our
> safeguard against people accidentally using SILENT_NO_TAINT_SUPPORT.
It's not really very messy at all. It would be in %Config, which is
how we check for threads support today.
Yes, some CPAN code will break and eventually people who care will fix
their tests for the possibility of a taint-removed Perl.
We had similar issues as 64 bit architectures became common. ok($num1
== $num2) tests were failing due to decimal point precision.
Let's not worry *too* much about CPAN. If a taint-disabled perl were
available, CPAN Testers would start smoking with it, and we'd have
very good visibility into what breaks and doesn't that authors can use
to fix their stuff (if they care) and users can use to decide if they
want to run taint-disabled or not.
Configuration-determined behaviors should have a *much* lower bar for
compatibility because acceptance of breakage is entirely the
end-users' choice.
David
--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg
Thread Previous
|
Thread Next