[perl #120903] perlcall problems, bad examples everywhere

[bulk88 (via RT)]

# New Ticket Created by bulk88
# Please include the string: [perl #120903]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=120903 >


This is a bug report for perl from ***@hotmail.com,
generated with the help of perlbug 1.39 running under perl 5.19.8.


-----------------------------------------------------------------
[Please describe your issue here]

perlcall is a jumbo sized rat trap.

-perlcall uses multiple repeated XPUSH* instead of EXTEND(SP, 1234),
unless you click "See XSUBs and the Argument Stack in perlguts
<http://perldoc.perl.org/perlguts.html#XSUBs-and-the-Argument-Stack> for
details on how the XPUSH macros work." you will never know about EXTEND

-perlcall, in "Using call_sv" tells people to keep SV*s in C statics,
which is threads incompatible, (should use MY_CXT, or put a comment in
the source code that this code is threads incompatible) and going to
leak without package cleaner xsub for the C side statics registered in
END block

-perlcall says to do a "dSP;" at the start of every callback sequence,
this only applies to C callback functions from C enumerators or event
loops functions, not a xsub calling back into perl, there is no mention
of how to have a xsub callback into perl, there is a

The exception to this rule is if you are calling a Perl subroutine
directly from an XSUB function. In this case it is not necessary
to use the |dSP| macro explicitly--it will be declared for you
automatically.

but some beginner XS authors didnt notice that IRL

-perlcall will need to be updated with whatever is decided for perlapi
docs for call_sv*, in perl RT #120826, current description in perlcall is

That is fine as far as it goes. The thing is, the Perl subroutine
can be specified as only a string, however, Perl allows references
to subroutines and anonymous subroutines. This is where
/call_sv/ is useful.

-what is a Perl subroutine on a C level?, related to #120826

- There is

printf ("The sum of %d and %d is %d\n", a, b, POPi);


in an example. perlcall never says POP* should never be used in
function-style args lists or POP* can never be multi-evaled or very bad
things will happen.

-Multi eval problems in this example, ERRSV in the GV will possibly be
created multiple times.

1. if (SvTRUE(ERRSV))
2. {
3. printf <http://perldoc.perl.org/functions/printf.html> ("Uh oh -
%s\n", SvPV_nolen(ERRSV));
4. POPs;
5. }


- Do we really need this in 2013/2014? Last updated maybe? IDK.

=head1 DATE

Version 1.3, 14th Apr 1997

The version 1.3 is from commit

Revision: 137443ea0a858c43f5a720730cac6209a7d41948
Author: Perl 5 Porters <perl5-***@africa.nicoh.com>
Date: 4/14/1997 8:00:00 AM
Message:
[inseparable changes from patch from perl-5.003_97d to perl-5.003_97e]


[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=docs
severity=low
---
Site configuration information for perl 5.19.8:

Configured by Owner at Thu Dec 26 04:12:47 2013.

Summary of my perl5 (revision 5 version 19 subversion 8) configuration:
Derived from:
Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -G7 -GL
-DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS
-DPERL_HASH_FUNC_ONE_AT_A_TIME -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T',
optimize='-O1 -MD -Zi -DNDEBUG -G7 -GL',
cppflags='-DWIN32'
ccversion='13.10.6030', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86'
libpth="C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib"
libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl519.lib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-opt:ref,icf -ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86'

Locally applied patches:
uncommitted-changes

---
@INC for perl 5.19.8:
C:/perl519/site/lib
C:/perl519/lib
.

---
Environment for perl 5.19.8:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=C:\perl519\bin;C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET
2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\Tools\bin\prerelease;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;
PERL_BADLANG (unset)
SHELL (unset)

[Leon Timmermans]

Post by bulk88 (via RT)
perlcall is a jumbo sized rat trap.
-perlcall uses multiple repeated XPUSH* instead of EXTEND(SP, 1234),
unless you click "See XSUBs and the Argument Stack in perlguts
<http://perldoc.perl.org/perlguts.html#XSUBs-and-the-Argument-Stack> for
details on how the XPUSH macros work." you will never know about EXTEND
-perlcall, in "Using call_sv" tells people to keep SV*s in C statics,
which is threads incompatible, (should use MY_CXT, or put a comment in
the source code that this code is threads incompatible) and going to
leak without package cleaner xsub for the C side statics registered in
END block
-perlcall says to do a "dSP;" at the start of every callback sequence,
this only applies to C callback functions from C enumerators or event
loops functions, not a xsub calling back into perl, there is no mention
of how to have a xsub callback into perl, there is a
The exception to this rule is if you are calling a Perl subroutine
directly from an XSUB function. In this case it is not necessary
to use the |dSP| macro explicitly--it will be declared for you
automatically.
but some beginner XS authors didnt notice that IRL
-perlcall will need to be updated with whatever is decided for perlapi
docs for call_sv*, in perl RT #120826, current description in perlcall is
That is fine as far as it goes. The thing is, the Perl subroutine
can be specified as only a string, however, Perl allows references
to subroutines and anonymous subroutines. This is where
/call_sv/ is useful.
-what is a Perl subroutine on a C level?, related to #120826
- There is
printf ("The sum of %d and %d is %d\n", a, b, POPi);
in an example. perlcall never says POP* should never be used in
function-style args lists or POP* can never be multi-evaled or very bad
things will happen.
-Multi eval problems in this example, ERRSV in the GV will possibly be
created multiple times.
1. if (SvTRUE(ERRSV))
2. {
3. printf <http://perldoc.perl.org/functions/printf.html> ("Uh oh -
%s\n", SvPV_nolen(ERRSV));
4. POPs;
5. }
- Do we really need this in 2013/2014? Last updated maybe? IDK.
=head1 DATE
Version 1.3, 14th Apr 1997
The version 1.3 is from commit
Revision: 137443ea0a858c43f5a720730cac6209a7d41948
Date: 4/14/1997 8:00:00 AM
[inseparable changes from patch from perl-5.003_97d to perl-5.003_97e]

I think the real problem with a lot of these documents is that they were
written some 15 years ago and never thoroughly updated. We should probably
go over them systematically at some point.

Leon

[Tony Cook via RT]

See the attached patches

Post by bulk88 (via RT)
perlcall is a jumbo sized rat trap.
-perlcall uses multiple repeated XPUSH* instead of EXTEND(SP, 1234),
unless you click "See XSUBs and the Argument Stack in perlguts
<http://perldoc.perl.org/perlguts.html#XSUBs-and-the-Argument-Stack>
for
details on how the XPUSH macros work." you will never know about
EXTEND

Covered I think.

Post by bulk88 (via RT)
-perlcall, in "Using call_sv" tells people to keep SV*s in C statics,
which is threads incompatible, (should use MY_CXT, or put a comment in
the source code that this code is threads incompatible) and going to
leak without package cleaner xsub for the C side statics registered in
END block

Covered, I think. Though I don't talk about clean-up.

Post by bulk88 (via RT)
-perlcall says to do a "dSP;" at the start of every callback sequence,
this only applies to C callback functions from C enumerators or event
loops functions, not a xsub calling back into perl, there is no
mention
of how to have a xsub callback into perl, there is a
The exception to this rule is if you are calling a Perl subroutine
directly from an XSUB function. In this case it is not necessary
to use the |dSP| macro explicitly--it will be declared for you
automatically.
but some beginner XS authors didnt notice that IRL

I think the current documentation is in the right place and says the right things, I don't think it's worthwhile repeating it again in different words.

It's not like we can go around smacking authors who don't read the documentation with a stick.

Post by bulk88 (via RT)
-perlcall will need to be updated with whatever is decided for perlapi
docs for call_sv*, in perl RT #120826, current description in perlcall
is
That is fine as far as it goes. The thing is, the Perl subroutine
can be specified as only a string, however, Perl allows references
to subroutines and anonymous subroutines. This is where
/call_sv/ is useful.

I'm not sure where this should go, other than just adding a pointer to perlapi/call_sv.

Post by bulk88 (via RT)
-what is a Perl subroutine on a C level?, related to #120826

Not sure what you're asking here.

Post by bulk88 (via RT)
- There is
printf ("The sum of %d and %d is %d\n", a, b, POPi);
in an example. perlcall never says POP* should never be used in
function-style args lists or POP* can never be multi-evaled or very
bad
things will happen.

That particular example looks fine to me. I've added a section warning about multiple evaluation of the POP macros.

Post by bulk88 (via RT)
-Multi eval problems in this example, ERRSV in the GV will possibly be
created multiple times.
1. if (SvTRUE(ERRSV))
2. {
3. printf <http://perldoc.perl.org/functions/printf.html> ("Uh oh -
%s\n", SvPV_nolen(ERRSV));
4. POPs;
5. }

Covered.

Post by bulk88 (via RT)
- Do we really need this in 2013/2014? Last updated maybe? IDK.
=head1 DATE
Version 1.3, 14th Apr 1997

I haven't removed it, but probably should.

Tony

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=120903