<URL: https://rt.cpan.org/Ticket/Display.html?id=54825 >
On Fri Jan 21 06:41:28 2011, JAWNSY wrote:
> Reopening for a very quick question: have you considered using
> Test::Warn? It will ensure the warnings are emitted, while at the same
> time suppressing them from test output.
I guess it would be ok to suppress those taint-related warnings from
the test suite output (if we can find a satisfactory way of doing
that). One way would be to set the config option 'NO_UNTAINT_WARN =>
1;' in the test script.
However, I'd rather *not* do that in case someone uses that test script
as a template, thereby running their scripts with 'NO_UNTAINT_WARN =>
1;', totally oblivious to the sorts of things that Inline is doing
under the hood.
My attempts at using Test::Warn to detect and suppress the warnings
have not yet worked:
#############################
use warnings;
use strict;
use Test::More tests => 1;
use Test::Warn;
use Inline Config =>
UNTAINT => 1,
DIRECTORY => '_Inline_test';
use Inline C => <<'END_OF_C_CODE';
int add(int x, int y) {
return x + y;
}
END_OF_C_CODE
warnings_are {add(3,4)} [];
#############################
The warnings are issued during Inline's build phase, before the
warnings_are() test is run - so I get output of:
#############################
1..1
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::check_config_file(): Blindly untainting Inline configuration
file information.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
ok 1
#############################
I'll keep looking at this (as time permits) until I either find a way
to make it work, or come to an understanding that it can't be made to
work.
Cheers,
Rob
