Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

non_bincompat_options is a lie #13904

Open
p5pRT opened this issue Jun 4, 2014 · 2 comments
Open

non_bincompat_options is a lie #13904

p5pRT opened this issue Jun 4, 2014 · 2 comments
Labels
Closable? We might be able to close this ticket, but we need to check with the reporter distro-mswin32 type-core

Comments

@p5pRT
Copy link

p5pRT commented Jun 4, 2014

Migrated from rt.perl.org#122032 (status was 'new')

Searchable as RT122032$
@p5pRT
Copy link
Author

p5pRT commented Jun 4, 2014 •
edited by toddr

From @bulk88

Created by @bulk88

I was looking through what creates -V. I find issues with
non_bincompat_options in S_Internals_V.

In PL_bincompat_options in perl.h it says

/* These are all the compile time options that affect binary compatibility.
Other compile time options that are binary compatible are in perl.c
Both are combined for the output of perl -V
However, this string will be embedded in any shared perl library, which will
allow us add a comparison check in perlmain.c in the near future. */

So PL_bincompat_options means, if its not identical between XS/object
code and the core, bad things will happen, and therefore
non_bincompat_options in S_Internals_V are the options that dont affect
the interaction between XS and the core. The meaning of
non_bincompat_options is not documented in perl.c.

The name of the var is incomprehensible to me. Does
non_bincompat_options mean, "these options create a state of no binary
compatibility between XS and core" or does it mean "these options do not
affect binary compatibility"?

Anyway since PL_bincompat_options defines one side, the other one is
implictly the other side.

Onto specific entries in non_bincompat_options.

PERL_DONT_CREATE_GVSV affects the definition of GvSVn in gv.h yet is in
non_bincompat_options

DEBUGGING affects existance of certain exports (Perl_pad_sv for example)
yet is in non_bincompat_options
, I have run into DLL export failures repeatedly when loading a
DEBUGGING XS DLL into a non-DEBUGGING perl, I dont remember if loading a
non-DEBUGGING XS DLL into a DEBUGGING perl works. dXSTARG contains
PAD_SV which is

#ifdef DEBUGGING
# define PAD_SV(po) pad_sv(po)
# define PAD_SETSV(po,sv) pad_setsv(po,sv)
#else
# define PAD_SV(po) (PL_curpad[po])
# define PAD_SETSV(po,sv) PL_curpad[po] = (sv)
#endif

PERL_IS_MINIPERL is in non_bincompat_options, miniperl has Dynaloader, OH RLY?

PERL_MEM_LOG is in non_bincompat_options, yet creates a
S_mem_log_common, Perl_mem_log_alloc, Perl_mem_log_realloc and
Perl_mem_log_free functions, if these dont exist in libperl, and the XS
module was compiled with this....

NO_TAINT_SUPPORT is in non_bincompat_options yet in sv.h I see

#ifdef NO_TAINT_SUPPORT
# define SvTAINTED(sv) 0
#else
# define SvTAINTED(sv) (SvMAGICAL(sv) && sv_tainted(sv))
#endif

Its not a very bad incompatibility, since I think sv_tainted still
exists with NO_TAINT_SUPPORT, and no struct changes. PL_tainted isn't
removed with this option. Maybe that is a bug.
 
NO_MATHOMS is in non_bincompat_options, if the mathom-ed funcs dont
exist in libperl, and the XS module was compiled with mathoms and uses them

PERL_NEW_COPY_ON_WRITE is in non_bincompat_options, yet sv.h has

# ifdef PERL_NEW_COPY_ON_WRITE
# define SvCANCOW(sv) \
(SvIsCOW(sv) \
? SvLEN(sv) ? CowREFCNT(sv) != SV_COW_REFCNT_MAX : 1 \
: (SvFLAGS(sv) & CAN_COW_MASK) == CAN_COW_FLAGS \
&& SvCUR(sv)+1 < SvLEN(sv))
/* Note: To allow 256 COW "copies", a refcnt of 0 means 1. */
# define CowREFCNT(sv) (*(U8 *)(SvPVX(sv)+SvLEN(sv)-1))
# define SV_COW_REFCNT_MAX ((1 << sizeof(U8)*8) - 1)
# define CAN_COW_MASK (SVf_POK|SVf_ROK|SVp_POK|SVf_FAKE| \
SVf_OOK|SVf_BREAK|SVf_READONLY)
# endif

which is, or isn't public API? but anyway, new COW and old COW use
different macros, if the flags were only used in .c files, it would be
okay, but if they are in .h, its questionable.

Perl Info 

Flags:
    category=core
    severity=low

Site configuration information for perl 5.21.1:

Configured by Owner at Wed May 28 03:57:28 2014.

Summary of my perl5 (revision 5 version 21 subversion 1) configuration:
  Local Commit: 1abbcfa06576bf8a6937c566bb4d18ba803b59d8
  Ancestor: 234105dd8a732de5fb48ccb1838c99281f89f669
  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:\perl521\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=perl521.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:\perl521\lib\CORE"  -machine:x86'

Locally applied patches:
    7494266ea378a3cdc4bfd51725012c1e432db0f1
    61961437d9453dd0d4053ad100e97a029a24edbb
    cd30b936fc5177ce169d776445d09c9898c15da1
    1abbcfa06576bf8a6937c566bb4d18ba803b59d8


@INC for perl 5.21.1:
    C:/perl521/site/lib
    C:/perl521/lib
    .


Environment for perl 5.21.1:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\perl521\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)

@toddr
Copy link
Member

toddr commented Feb 13, 2020

I don't see anything actionable here.

@toddr toddr added the Closable? We might be able to close this ticket, but we need to check with the reporter label Feb 13, 2020
@xenu xenu removed the affects-5.21 label Nov 19, 2021
@xenu xenu removed the Severity Low label Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closable? We might be able to close this ticket, but we need to check with the reporter distro-mswin32 type-core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@toddr @xenu @p5pRT