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: @xdgThread Previous | Thread Next