On Tue, Jan 8, 2013 at 11:02 PM, Craig A. Berry <craigbe...@mac.com> wrote:
> On Jan 8, 2013, at 9:14 PM, Thomas Pfau <tfp...@gmail.com> wrote: > > > It looks like the definition of PL_sv_undef has something to do with > threads. Could this be broken because I enabled threads in my build? > > It doesn't have anything to do with threads directly, except all PL_xxx > global variables are not really global variables under threads, but are > instead members of the interpreter struct. > > > On Tue, Jan 8, 2013 at 9:24 PM, Thomas Pfau <tfp...@gmail.com> wrote: > > This is even causing problems with the generated constant function. If > I try to get the value of a constant I get this: > > > > $x = &VMS::CMS::CMS_K_ACCEPT > > The ampersand is forcing it to be interpreted as a subroutine call, but > that's not really a subroutine is it? > Yes. References to constants are resolved using AUTOLOAD which treats it like a subroutine. The subroutine returns the value of the constant. > Bizarre copy of UNKNOWN in list assignment at > /DISK$USERS/PFAU/PROG/PERL/vms-cms/blib/lib/VMS/CMS.pm line 490. > > The error message means it doesn't know the type of the scalar that's > having its flags checked (search for "Bizarre" in sv.c). I see that most > of your routines have return values of type SV *, so I would think that > instead of > > RETVAL = &PL_sv_undef; > > you would want: > > RETVAL = (SV *) &PL_sv_undef; > > but I don't know if that would help with the immediate problem. > I don't think that would help. RETVAL should be declared by the XS generation code as SV* so I don't think the cast would accomplish anything. I'll take a look at the generated C code. I haven't had time to download your module and try it. Is the one on CPAN > the latest? > Yes, the one on CPAN exhibits the problem. -- Thomas Pfau tfp...@gmail.com http://www.linkedin.com/in/thomaspfau http://nbpfaus.net/~pfau/
