p5pRT
commented
10 years ago 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)
#endifPERL_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))
#endifIts 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)
# endifwhich 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.
toddr
Migrated from rt.perl.org#122032 (status was 'new')
Searchable as RT122032$