portable no warnings "uninitialized"

[DKW]

Hi

I'm writing a script which should be as portable as possible.

The version I'm programming in is v5.6.1
and here I can use the following code:

no warnings "uninitialized";


When I try to use that code on another site, where they have an older
version of perl, it complains about this code
(I can't give you the details 'cause I don't have access to that site
right now)

How can I make it portable, so the script avoid the code:
no warnings "uninitialized";
if it's not available (as in older perl)

(I can live with the "uninitialized"-warnings for the older perl)

tia

 

[Peter Scott]

Hi

I'm writing a script which should be as portable as possible.

The version I'm programming in is v5.6.1
and here I can use the following code:

no warnings "uninitialized";


When I try to use that code on another site, where they have an older
version of perl, it complains about this code
(I can't give you the details 'cause I don't have access to that site
right now)

How can I make it portable, so the script avoid the code:
no warnings "uninitialized";

Replace that line with

local $^W = 0;

 

[Gunnar Hjalmarsson]

I'm writing a script which should be as portable as possible.

The version I'm programming in is v5.6.1
and here I can use the following code:

no warnings "uninitialized";

When I try to use that code on another site, where they have an older
version of perl, it complains about this code
(I can't give you the details 'cause I don't have access to that site
right now)

How can I make it portable, so the script avoid the code:
no warnings "uninitialized";
if it's not available (as in older perl)

The options I can see are to either fix the code so it doesn't generate
uninitialized warnings, or turn off warnings in the production code (but
keep it enabled during development and maintenance).

 

[DKW]

Wouldn't that turn of _all_ warnings locally, not just the
"uninitialized" category?

 

[DKW]

The options I can see are to either fix the code so it doesn't generate
uninitialized warnings, or turn off warnings in the production code (but
keep it enabled during development and maintenance).

As I wrote in the first post, I want to turn of _only_ the warning
category "uninitialized",
which seems to be possible with the code:
no warnings "uninitialized";
at least from v5.6.1.

However, this will give an error if you try it in perl versions prior
to 5.6 when the warnings module was introduced.

If I rephrase my question:
Can you at runtime check for existence for a module,
and use (or no) it if it exists?

 

[Gunnar Hjalmarsson]

As I wrote in the first post, I want to turn of _only_ the warning
category "uninitialized",

I understood that, but I wasn't able to figure out a way to do it if you
want the script to also work with pre 5.6.0 Perl versions.

If I rephrase my question:
Can you at runtime check for existence for a module, and use (or no)
it if it exists?

For an ordinary module you can do e.g.:

BEGIN { eval "use SomeModule" }

but the problem with "warnings" is that it's a pragma whose effect is
set lexically.

 

[Peter Scott]

Wouldn't that turn of _all_ warnings locally, not just the
"uninitialized" category?

Yes. Selective warnings didn't exist in the perls you're trying
to make this work on.

What you could do instead is set up a handler for $SIG{__WARN__}
and inspect the text before deciding what to do with it. See
perldoc perlvar.

 

[Brian McCauley]

I understood that, but I wasn't able to figure out a way to do it if you
want the script to also work with pre 5.6.0 Perl versions.



For an ordinary module you can do e.g.:

BEGIN { eval "use SomeModule" }

but the problem with "warnings" is that it's a pragma whose effect is
set lexically.

That does not prevent the more verbose form from working:

BEGIN {
if ( eval { require warnings; 1 } ) {
warnings->unimport('uninitialized');
}
}

Or even just

BEGIN {
eval {
require warnings;
warnings->unimport('uninitialized');
}
}

 

[Gunnar Hjalmarsson]

That does not prevent the more verbose form from working:

BEGIN {
if ( eval { require warnings; 1 } ) {
warnings->unimport('uninitialized');
}
}

Or even just

BEGIN {
eval {
require warnings;
warnings->unimport('uninitialized');
}
}

Hmm.. So

no warnings 'uninitialized';

does only affect the current block, while

warnings->unimport('uninitialized');

is more widely applied. Is the latter file scoped or dynamically scoped?
Btw, is it documented anywhere?

Anyway: Thanks, Brian, that should be exactly what the OP is looking for.

 

[DKW]

Thank you all, guys!

I will try some of these techniques.

 

[Brian McCauley]

Hmm.. So

no warnings 'uninitialized';

does only affect the current block, while

warnings->unimport('uninitialized');

is more widely applied. Is the latter file scoped or dynamically scoped?

The glib answer is that dynamic scope at compile time becomes lexical
scope at runtime.

That's not really the whole story but it's a starting point.

The point is that...

no warnings 'uninitialized';

....is short for...

BEGIN {
require warnings;
warnings->unimport('uninitialized');
}

....which in turn is more or less a bit like ...

BEGIN {
${^WARNING_BITS} &= ~some_constant_denoting_uninitialised;
}

The point is that what is happening is that the value of the special
variable ${^WARNING_BITS} that's getting changed at compile time. This
special variable is pushed every time the compiler starts to compile a
new block and poped when it compeletes the compilation of the block.
During the compilation the bits of ${^WARNING_BITS} control compile time
warnings. Somehow the generated opcode tree also remembers the relevant
bits of ${^WARNING_BITS} from when it was generated so that runtime
errors behave as lexically scoped too.

Note the closing brace of the BEGIN block does not undo the effect of
the code within the BEGIN block because the code in a BEGIN block is
executes as soon as the complier has passed the closign brace.