develooper Front page | perl.perl5.porters | Postings from December 2013

[perl #120903] perlcall problems, bad examples everywhere

Thread Next
December 30, 2013 20:05
[perl #120903] perlcall problems, bad examples everywhere
Message ID:
# New Ticket Created by  bulk88 
# Please include the string:  [perl #120903]
# in the subject line of all future correspondence about this issue. 
# <URL: >

This is a bug report for perl from,
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 
<> 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

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 <> ("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 <>
Date: 4/14/1997 8:00:00 AM
[inseparable changes from patch from perl-5.003_97d to perl-5.003_97e]

[Please do not change anything below this line]
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:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    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
    cc='cl', ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -G7 -GL 
    optimize='-O1 -MD -Zi -DNDEBUG -G7 -GL',
    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', 
    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
  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:

@INC for perl 5.19.8:

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 
    PERL_BADLANG (unset)
    SHELL (unset)

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About