bulk88

I will also add, Perl/P5P devs might be be able to in C lang, in certain permutations of CC OS and CPU, outsmart a C compiler's native UA mem read/write...

Here is a reason why `memcpy()` and `memcmp()` can't be blindly assumed to be a magical UA memory compliance tool and a C dev STILL needs to read their CC's...

> It also introduces more aliasing issues (e.g. `src` accessed with both `U64*` and `U32*`) which is a shame, as it brings Perl further away from dropping `-fno-strict-aliasing`. I don't...

I'll also add byte order swapping, more specifically swapping the byte order of a 64 bit variable aka htonll()/ntohll(), was a patented technology until 2022 and perl has been doing...

MSVC fix branch pushed at https://github.com/Perl/perl5/pull/23374 Reasons for all the MSVC specific code is, here is very poor code gen round 1, after getting the syntax errors fixed. ``` 48...

BEFORE 5.41.7 ``` C:\sources\perl5>timeit C:\pb64\bin\perl.exe -e "my $x = \"X\"x(1024*1000*10); my $y; for (0..1_000) { $y = reverse \"foo\",$x }" Exit code : 0 Elapsed time : 10.20 Kernel time...

> My PR at #23330 by coincidence is trying to ADD THE INTRINSICS to the Perl C API, that THIS PR WANTS to use. But the ticket has stalled. >...

> Just trying to understand where this PR is at now: > > * I think it the two wide-reverse sections can (probably) be merged with a bit of refactoring....

> Some senior GCC dev said in a WWW post/article, GCC's policy is `memcpy()` the direct equivalent of `.toString()` or `.toJSON()`, and GCC's policy/position statement is that any attempt to...

> Assuming `memcpy()` is `ISO C`'s synonym for fast unaligned mem reads/writes in ASM lang, is highly illegal !!! > > Reason is because inlining `libc.so`s external linkage `memcpy()` symbol...