portable no warnings "uninitialized"

Discussion in 'Perl Misc' started by DKW, Jan 10, 2005.

  1. DKW

    DKW Guest

    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
    DKW, Jan 10, 2005
    #1
    1. Advertising

  2. DKW

    Peter Scott Guest

    In article <>,
    "DKW" <> writes:
    >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;

    --
    Peter Scott
    http://www.perldebugged.com/
    *** NEW *** http://www.perlmedic.com/
    Peter Scott, Jan 10, 2005
    #2
    1. Advertising

  3. DKW wrote:
    > 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).

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Jan 10, 2005
    #3
  4. DKW

    DKW Guest

    Wouldn't that turn of _all_ warnings locally, not just the
    "uninitialized" category?
    DKW, Jan 11, 2005
    #4
  5. DKW

    DKW Guest

    Gunnar Hjalmarsson wrote:
    > 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?
    DKW, Jan 11, 2005
    #5
  6. DKW wrote:
    > Gunnar Hjalmarsson wrote:
    >> 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",


    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.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Jan 11, 2005
    #6
  7. DKW

    Peter Scott Guest

    In article <>,
    "DKW" <> writes:
    [In response to my suggestion to insert "local $^W = 0"]
    >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.

    --
    Peter Scott
    http://www.perldebugged.com/
    *** NEW *** http://www.perlmedic.com/
    Peter Scott, Jan 11, 2005
    #7
  8. Gunnar Hjalmarsson wrote:

    > DKW wrote:
    >
    >> Gunnar Hjalmarsson wrote:
    >>
    >>> 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",

    >
    >
    > 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.


    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');
    }
    }
    Brian McCauley, Jan 11, 2005
    #8
  9. Brian McCauley wrote:
    > Gunnar Hjalmarsson wrote:
    >> DKW wrote:
    >>> 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.

    >
    > 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.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Jan 11, 2005
    #9
  10. DKW

    DKW Guest

    Thank you all, guys!

    I will try some of these techniques.
    DKW, Jan 14, 2005
    #10
  11. Gunnar Hjalmarsson wrote:

    > Brian McCauley wrote:
    >
    >> Gunnar Hjalmarsson wrote:
    >>
    >>> DKW wrote:
    >>>
    >>>> 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.

    >>
    >> 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?


    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.
    Brian McCauley, Jan 14, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bill McNeill
    Replies:
    1
    Views:
    88
    Eric Hodel
    Oct 18, 2007
  2. Ted Sung
    Replies:
    1
    Views:
    307
    Sherm Pendley
    Aug 30, 2004
  3. Replies:
    3
    Views:
    178
  4. julia
    Replies:
    6
    Views:
    100
    Uri Guttman
    Jan 5, 2007
  5. Tomasz Chmielewski
    Replies:
    12
    Views:
    168
Loading...

Share This Page