Re: XS question on Windows

Glenn Linderman Mon, 23 Jun 2003 13:04:16 -0700

On approximately 6/22/2003 11:16 PM, came the following characters from
the keyboard of Sisyphus:

> I have a module (let's call it Mymod) that contains an XS function (let's
> call it myfunc). "myfunc()" takes 3 arguments (integers).
>
> I'll get the exact same warning as you reported if I run the following
> script:

OK, so then you are talking about references to uninitialized variables
passed to a "real" (vs uninitialized) subroutine.

Even pure perl code doesn't complain until the uninitialized variable is
used, so yes, I would imagine that to be the case.

But note that these are not parameters being referenced here, but rather
  variables that are internal to the Win32::GUI::Create call itself.

Certainly none of the variables referenced near the failing line of code
are directly from parameters.

> So .... I was thinking of getting a "print" of $self, $type and @input > (before GUI.pm calls 'Win32::GUI::Create()') to determine just which value > is uninitialised - and if, say, it turns out to be $type, then insert code > (once again, before the Win32::GUI::Create() call): > if(!$type) {$type = 0} > That's also assuming that 0 is an appropriate value for $type when $type is > uninitialised.

Right; I've been able to diagnose this sort of thing from the outside of
various modules, including even some of the calls to Win32::GUI.... but
failed on this one, it just sort of happens, and the inputs all seem OK.

> You then face the problem that if $type has not been initialised (but *needs > to* have been) you're not going to be told about it. > > I really don't know off-hand which argument is uninitialised. I guess it > will be either $type or one of the elements in @input. You'd need to run > those 'print's to find out.

I'll do this, just to be sure, but I'm not expecting useful results.

OK, I've done it, and here is the output (the print was already, there,
but commented out).  Didn't get any additional warnings, just the two
that had been there all along.

PM(Win32::GUI::_new) self='Win32::GUI::Label=HASH(0x24f0fd0)' type='11'
input='Win32::GUI::MDI=HASH(0x24ed34c) -name label_bitmap -height 327
-left 0 -tip list display area -top 0 -bitmap 1 -width 552 -foreground
ARRAY(0x24eb95c) -font Win32::GUI::Font=HASH(0x1eccdac)'
XS(Create): t 15d425c *t 24f3a78
Use of uninitialized value in subroutine entry at
C:/Perl/site/lib/Win32/GUI.pm line 524.
PM(Win32::GUI::_new) self='Win32::GUI::Button=HASH(0x24f1054)' type='12'
input='Win32::GUI::Window=HASH(0x1a8a7ac) -left 238 -visible 1 -tip
Configuration options menu -width 60 -name b_config -height 40 -text
Config -top 327 -foreground ARRAY(0x24eb95c) -font
Win32::GUI::Font=HASH(0x1eccdac)'
XS(Create): t 15d425c *t 24f77a8
Use of uninitialized value in subroutine entry at
C:/Perl/site/lib/Win32/GUI.pm line 524.
PM(Win32::GUI::_new) self='Win32::GUI::Button=HASH(0x24f37a8)' type='12'
input='Win32::GUI::Window=HASH(0x1a8a7ac) -left 298 -visible 1 -tip List
display size configuration -width 60 -name b_size -height 40 -text Size
-top 327 -foreground ARRAY(0x24eb95c) -font
Win32::GUI::Font=HASH(0x1eccdac)'

>>From my tests, it looks to me that perl doesn't check to see whether the > arguments supplied to myfunc() have been initialised - irrespective of > whether myfunc() is an XS or a pure perl function. The fact that one of the > arguments is uninitialised doesn't get detected until myfunc() comes to use > that argument. At that point, if myfunc() is an XS function, you'll get > warned of the uninitialised value in the "subroutine entry". If myfunc() is > a perl function, however, you'll get warned of the uninitialised value in > "multiplication" (or whatever it was that myfunc() tried to do with the > uninitialised value).

I agree.

> I think that the line that you identified in the XS code marks the point > where the uninitialised nature of one of the arguments is first detected - > which triggers the warning you get.

And I'm thinking that it marks the point of a bug, in setting up some
internal-to-the-XS-code state variables.

So I added "sv_dump(*t);" just before the line marked ----->, and got

SV = PVMG(0x24f28b4) at 0x24f3a78
   REFCNT = 1
   FLAGS = (TEMP,SMG,RMG)
   IV = 0
   NV = 0
   PV = 0
   MAGIC = 0x24f5b54
     MG_VIRTUAL = &PL_vtbl_packelem
     MG_TYPE = PERL_MAGIC_tiedelem(p)
     MG_FLAGS = 0x06
       REFCOUNTED
       GSKIP
     MG_OBJ = 0x24f0e20
         SV = RV(0x24eda50) at 0x24f0e20
           REFCNT = 8
           FLAGS = (ROK)
           RV = 0x24ed394
     MG_LEN = 8
     MG_PTR = 0x24f5b84 "-tooltip"

So... this seems to say it is a tied element?  So does that mean there
is a whole 'nuther subroutine to look at somewhere (I wonder where) to
analyze the uninitialized variables of?

By the way, I just noticed that this got "off-list", that was probably
an unintentional "reply" instead of "reply-all" on my part, so I'm
putting in back on-list in case this new informatino triggers someone
else's ideas/thoughts.

> Cheers,
> Rob

--
Glenn -- http://nevcal.com/
===========================
Wise men talk because they have something to say.
Fools talk because they have to say something." -- Plato

_______________________________________________
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: XS question on Windows

Reply via email to