----- Original Message ----- 
From: "Jan Dubois" <[EMAIL PROTECTED]>
To: "'Sisyphus'" <[EMAIL PROTECTED]>; "'xs'" <perl-xs@perl.org>
Sent: Thursday, June 22, 2006 12:46 AM
Subject: RE: Perl_report_uninit on Win32


> On Tue, 20 Jun 2006, Sisyphus wrote:
> >
> > The following Inline::C script runs fine on linux (perl 5.8.8):
>
> I don't really see a use case where you would have to call report_uninit()
> explicitly in a module, but if you do, maybe this will work:
>
>        (void)SvIV(PL_sv_undef);
>

For some reason it's used in CDB_File-0.94 (and possibly earlier) which is
now maintained by Matt Sergeant. There are 4 occurrences of something like:

 if (!SvOK(k)) {
  if (ckWARN(WARN_UNINITIALIZED)) Perl_report_uninit(aTHX);
  XSRETURN_UNDEF;
        }

Not that I need to build the module - the point about the unlinkability of
Perl_report_uninit on Win32 was raised in a perlmonks thread. I had not come
across that type of situation before and couldn't work out why it would be
happening ..... didn't know about embed.fnc, or the role it played :-)

Based on the output of the Inline::C script (posted here earlier) I tried
changing it to:
if (ckWARN(WARN_UNINITIALIZED)) warn ("Use of uninitialized value in
subroutine entry");

With that change in place, the module still built and tested fine on linux.
On Win32, it then builds fine, but some of the tests fail .... but that's
possibly because of *another* kludge to work around the module's call to
fsync().

Anyway, like I said, I don't feel a need to build this module ... but I did
feel a need to *understand* the problem. Thanks for providing that
understanding.

Cheers,
Rob

Reply via email to