From @bulk88

Created by @bulk88

While helping someone in #xs, a problem (in returned list, same SV *
showed up twice, which is impossible) was ultimatly solved by putting
PUTBACK and SPAGAIN around a func that calls eval_pv.

---------------------------------------------
SV * xcall(pTHX) {
  SV* sv = eval_pv("Foo​::get()",0);
  return sv;
}

for(i = 0; i< cnt; i++) {
  SV * sv;
  PUTBACK;
  sv = xcall(aTHX);
  SPAGAIN;
  XPUSHs(sv);
}
---------------------------------------------

perlcall barely says anything about the 2 eval_* funcs, they are more
documented in perlapi than perlcall.

So there are 2 questions which need to be answer in perlapi

-do eval_pv and eval_sv take PUSHMARK(SP); and @​_ args?
-do eval_pv and eval_sv need PUTBACK/SPAGAIN protection?

My testing shows eval_pv does NOT take perl stack params, but in a edge
case @​_ has elements from 2 callers up.

---------------------------------------------
MODULE = LXS PACKAGE = LXS

void
call_pvwithPUSHedargs(...)
CODE​:
  PUSHMARK(SP);
  mXPUSHi(6);
  mXPUSHi(7);
  PUTBACK;
  call_pv("LXS​::eval_pv_withPUSHedargs", 1);
  SPAGAIN;

void
eval_pv_withPUSHedargs(...)
CODE​:
  PUSHMARK(SP);
  mXPUSHi(4);
  mXPUSHi(5);
  PUTBACK;
  eval_pv("&Dump;", 1);
-----------------------------------------------

use Data​::Dumper;
use LXS;

sub run1 {
LXS​::eval_pv_withPUSHedargs(9,10);
}
print "going to go through eval_pv, Dump should see 9,10 or 4,5 but sees
1,2 instead\n";
run1(1,2);

sub run2 {
goto &Dump;
}
print "goto &Dump directly in PP, this is correct\n";
run2(3,4);

sub Dump{
  print "in Dump got ".@​_." args\n";
  print Data​::Dumper​::Dumper(@​_);
}

print "going to go through call_pv, then into eval_pv, nada, zero args\n";
LXS​::call_pvwithPUSHedargs(8,9);
-------------------------------------------------
C​:\Documents and Settings\Owner\Desktop\cpan libs\lxs>perl t.pl
going to go through eval_pv, Dump should see 9,10 or 4,5 but sees 1,2
instead
in Dump got 2 args
$VAR1 = 1;
$VAR2 = 2;
goto &Dump directly in PP, this is correct
in Dump got 2 args
$VAR1 = 3;
$VAR2 = 4;
going to go through call_pv, then into eval_pv, nada, zero args
in Dump got 0 args

C​:\Documents and Settings\Owner\Desktop\cpan libs\lxs>
-------------------------------------------------

So what is eval_pv's behavior with @​_? If we aren't going to implement
eval_pv taking a @​_, then @​_ should ALWAYS BE EMPTY. Not the edge case I
banged out above. Or fix eval_pv to take @​_ args from XS and PP. IDK.

Flags:
    category=docs
    severity=low

Site configuration information for perl 5.19.12:

Configured by Owner at Tue Apr 29 12:19:05 2014.

Summary of my perl5 (revision 5 version 19 subversion 12) configuration:
  Derived from: 605728659d1010fcc2bbda42f494757fe6a6126e
  Ancestor: 9e9002efd1609c7d154f98af43a026320df7582c
  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
    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
    605728659d1010fcc2bbda42f494757fe6a6126e


@INC for perl 5.19.12:
    C:/perl519/site/lib
    C:/perl519/lib
    .


Environment for perl 5.19.12:
    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)

From @Leont

On Sun, May 18, 2014 at 1​:58 AM, bulk88 <perlbug-followup@​perl.org> wrote​:

While helping someone in #xs, a problem (in returned list, same SV *
showed up twice, which is impossible) was ultimatly solved by putting
PUTBACK and SPAGAIN around a func that calls eval_pv.

---------------------------------------------
SV * xcall(pTHX) {
SV* sv = eval_pv("Foo​::get()",0);
return sv;
}

for(i = 0; i< cnt; i++) {
SV * sv;
PUTBACK;
sv = xcall(aTHX);
SPAGAIN;
XPUSHs(sv);
}
---------------------------------------------

perlcall barely says anything about the 2 eval_* funcs, they are more
documented in perlapi than perlcall.

So there are 2 questions which need to be answer in perlapi

-do eval_pv and eval_sv take PUSHMARK(SP); and @​_ args?

Why would it?

-do eval_pv and eval_sv need PUTBACK/SPAGAIN protection?

Anything function (core or the module's) that manipulates the stack needs
PUTBACK/SPAGAIN protection. Mentioning this in perlapi is good, but
actually explaining why this is necessary in perlguts is better (this isn't
just a calling issue, so perlcall doesn't quite feel like the right place
to me).

My testing shows eval_pv does NOT take perl stack params, but in a edge
case @​_ has elements from 2 callers up.

That's because «&function;» inherits the @​​::_, not the stack values. I
don't see why anyone would want to do this, so I can't be bothered by it.

Leon

The RT System itself - Status changed from 'new' to 'open'

Given the question was answered, I'm closing this case.