The Perl_Config struct has to be 8 or 16 bytes always. Disabling that assert means there is a bug somewhere else or unused padding/alignment bytes that could be used to store larger inline strings (1 less ptr worth of bytes in DLL and 1 less relocation record in DLL and no padding bytes till next 4/8 byte alignment for the C string) vs pointer strings. Can you give a console example of the error or reproduce that error again?
I am thinking of releasing another XSConfig that adds UINT64_C() or ULL suffix to the inline strings on 64 bit because I get
Config.c:6499: warning: integer constant is too large for 'long' type
on 64 bit builds for inline stored strings (written as 64 bit hex literals) and also
I gotta fix
Config.c:6461: warning: cast from pointer to integer of different size
because (U16)(long)(&((struct stringpool_t *)0)->stringpool_str7757), the (long) truncates the pointer and it should be size_t/perl portable version of size_t before the downcast to U16 but I have to check the commit history how we cast that.
I dont like the XSRETURN_UNDEF because that does some more reads/writes to globals/increases liveness. All exit paths originally goto one exit path that writes a SV * on a precomputed stack slot, and the globals are set up at the begining to always return 1 element, then the vars like ax go out of liveness by the CC. Without XSRETURN_UNDEF (IE, with the "goto return_undef") XS_Config_FETCH func is 0xE0 machine code bytes long. With XSRETURN_UNDEF it is 0x102 bytes long.
I'd rather fix the "error: jump to label 'return_undef' [-fpermissive]" by scope/decl changes than put in XSRETURN_UNDEF. Which compiler version did you use to get the "error: jump to label 'return_undef' [-fpermissive]". I tried GCC 7.1.0 with "-x c++" and I didn't get any errors compiling the "goto return_undef" code. What CC did you see that with?
Last week I took most of the changes you did in 2017 to XSConfig and put them on cpan Tests look good http://www.cpantesters.org/distro/X/XSConfig.html .
There are 2 commits I didn't integrate and need more explanation.
https://github.com/perl11/cperl/commit/967c649142e87abfd9d7dc46dc41b26bbb9c5894
The Perl_Config struct has to be 8 or 16 bytes always. Disabling that assert means there is a bug somewhere else or unused padding/alignment bytes that could be used to store larger inline strings (1 less ptr worth of bytes in DLL and 1 less relocation record in DLL and no padding bytes till next 4/8 byte alignment for the C string) vs pointer strings. Can you give a console example of the error or reproduce that error again?
I am thinking of releasing another XSConfig that adds UINT64_C() or ULL suffix to the inline strings on 64 bit because I get
on 64 bit builds for inline stored strings (written as 64 bit hex literals) and also I gotta fix
because (U16)(long)(&((struct stringpool_t *)0)->stringpool_str7757), the (long) truncates the pointer and it should be size_t/perl portable version of size_t before the downcast to U16 but I have to check the commit history how we cast that.
Also
https://github.com/perl11/cperl/commit/dca2eedf378d3ac96727a5558ed4f9e9e98b1192
I dont like the XSRETURN_UNDEF because that does some more reads/writes to globals/increases liveness. All exit paths originally goto one exit path that writes a SV * on a precomputed stack slot, and the globals are set up at the begining to always return 1 element, then the vars like ax go out of liveness by the CC. Without XSRETURN_UNDEF (IE, with the "goto return_undef") XS_Config_FETCH func is 0xE0 machine code bytes long. With XSRETURN_UNDEF it is 0x102 bytes long.
I'd rather fix the "error: jump to label 'return_undef' [-fpermissive]" by scope/decl changes than put in XSRETURN_UNDEF. Which compiler version did you use to get the "error: jump to label 'return_undef' [-fpermissive]". I tried GCC 7.1.0 with "-x c++" and I didn't get any errors compiling the "goto return_undef" code. What CC did you see that with?