In several places in Win32::GUI XS code there are warnings printed.
When this happens, there is (as far as I have checked) always test 'if
(PL_dowarn)' around the warning. Now, I'm sure there is some Perl
history here, as the documentation (perlintern) clearly states that
PL_dowarn is the XS programmer's equivalent of $^W. It is not!
PL_dowarn is a bitmask that conveys a whole load of global warning state
(See perl's warnings.h for more details). The upshot of this is that
the *only* way to silence such messages from Win32::GUI is to ensure
that you start perl with no warning command line switches (none of -w,
-W or -X) and to not have a 'use warnings' line anywhere in your code.
{Yes, currently -X on the command line results in Win32::GUI splitting
out warnings :-) (you can also use a $SIG{__WARN__} hook, but you need
to know the characteristics of the messages you want to silence to do
this - see my recent post to the users list).
This is obviously an undesirable situation.
Using (PL_dowarn & G_WARN_ON) instead is the direct equivalent of
checking $^W. The downside of this is that 'use warnings' does not set
$^W, and so making this change will result in most current code
silencing these warnings. To turn them on you need to use -w, -W
(command line) or $^W=1 (in your code). But at least we'd have a way
to control whether such messages are emitted.
I see 4 possible ways forward:
(1) Leave it as it is, and wait for Perl 5.9 which will (from what I
read) extend the 'warnings::warnif' mechanism to XSUBS.
(2) Change to checking against (PL_dowarn & G_WARN_ON), with the side
effects mentioned above, and highlighting the change in release
notes/readme.
(3) Introduce a package global (Win32::GUI::WARNINGS?) that the user can
set to control warnings, defaulting to on (matching the current behaviour)
(4) Review the warnings that we have, and decide if they are needed, or
if there are other ways to behave. (for example the irritating warnings
about -style being deprecated could perhaps be removed, as I think it is
a useful option). This route may be orthogonal to the other 3, as we
may want to do this anyway, and if we have any warnings left, then we
will still need to pick one of the other 3 options.
My vote is for (2). Comments?
Regards,
Rob.
Further background:
