perl11 / cperl

A perl5 with classes, types, compilable, company friendly, security
http://perl11.org/
Other
142 stars 17 forks source link

XSConfig cpan integration #367

Open bulk88 opened 6 years ago

bulk88 commented 6 years ago

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

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.

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?

rurban commented 6 years ago

Great. Regarding the 1st, I only know the bits from my commit message. Msvc110free

The 2nd: yes fixing the jump error is also fine. This was clang++ I assume, but I can retry. I try with many compilers.