Perl_report_uninit on Win32

[Sisyphus]

Hi,

The following Inline::C script runs fine on linux (perl 5.8.8):

-- try.pl --
use warnings;
use Inline C => Config => BUILD_NOISY => 1;

use Inline C => <<'EOC';

void foo() {
Perl_report_uninit(aTHX);
}

EOC

foo(); # line 12
__END__
---------

The output is:
Use of uninitialized value in subroutine entry at try.pl line 12.

However, when I run the same script on Win32 (perl 5.8.8 and earlier), it
won't compile:
try_pl_6d5f.o(.text+0xf):try_pl_6d5f.c: undefined reference to
`Perl_report_uninit`

On Win32,'Perl_report_uninit' simply aint there in libperl58.a (or
libperl58.lib, as the case may be).

Anyone know what to use instead of Perl_report_uninit() on Win32 ?

Is there something happening here that p5p should be aware of ?

Cheers,
Rob

[Jan Dubois]

Post by Sisyphus
On Win32,'Perl_report_uninit' simply aint there in libperl58.a (or
libperl58.lib, as the case may be).
Anyone know what to use instead of Perl_report_uninit() on Win32 ?
Is there something happening here that p5p should be aware of ?

No, Perl_report_uninit() is not a public Perl API, so extensions are not
allowed to call it. On Linux this cannot be enforced as all internal
symbols are being exported anyways, but on Windows (and AIX) you can
only call APIs that are marked as "public" in the embed.fnc file in
the core Perl distribution.

In general it is a good idea to check `perldoc perlapi`. If the function
isn't listed in there, then you are not allowed to use them in an extension.

Cheers,
-Jan

[Sisyphus]

----- Original Message -----
From: "Jan Dubois"
.
.

Post by Jan Dubois
In general it is a good idea to check `perldoc perlapi`. If the function
isn't listed in there, then you are not allowed to use them in an extension.

And yet there's no problem with resolving 'Perl_seed' (which is explicitly
called in the core module Scalar::List::Utils) - despite the fact that
'Perl_seed' is mentioned in neither 'perldoc perlapi' nor 'embed.fnc'.

Cheers,
Rob

[Sisyphus]

----- Original Message -----
From: "Steve Hay"
.
.

Post by Sisyphus
And yet there's no problem with resolving 'Perl_seed' (which is explicitly
called in the core module Scalar::List::Utils) - despite the fact that
'Perl_seed' is mentioned in neither 'perldoc perlapi' nor 'embed.fnc'.

It is mentioned in embed.fnc -- but as "seed" rather than "Perl_seed".
Ap |U32 |seed
in which the "p" means that the function has a "Perl_" prefix :-)
(See notes at the top of the file.)

Yes - quite so. Thanks Steve, Jan.

Cheers,
Rob

[Jan Dubois]

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);

Cheers,
-Jan

[Sisyphus]

----- Original Message -----
From: "Jan Dubois" <***@activestate.com>
To: "'Sisyphus'" <***@optusnet.com.au>; "'xs'" <perl-***@perl.org>
Sent: Thursday, June 22, 2006 12:46 AM
Subject: RE: Perl_report_uninit on Win32

Post by Jan Dubois
I don't really see a use case where you would have to call report_uninit()
(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