cperl

Im missing the wrongly categorized 2 korean hangul fillers. They are in identifiers, but are not. So languages accepting identifiers and care about security (there are only two) must reject them. https://github.com/perl11/cperl/issues/166

To be on topic: Perl7 is basically the idea to modernize saner settings by default. And breaking backcompat where it hurts. But it's far off a modern perl, like cperl is. They failed to fix the worst historical design mistakes. The hashes, the OO, types, @_, attrs before signatures (which was a major breaking change, but they excused themselves by claiming it was experimental), and many more. https://github.com/perl11/cperl/issues/414 Instead they are breaking indirect method calls. Thanksfully this will be not POSIX, so nobody will use it.

I like that idea, it's just not that easy. How to do define module versions and inheritance, when you are not allowed to do global assignments in the module. declarations only, and no IO or global side effect is fine, but declaring versions and inheritance need to be allowed in global scope. I added these ideas here: https://github.com/perl11/cperl/issues/406

I think Rieni Urban abandoned working on this project over cperl. https://github.com/perl11/cperl

I'm doing that successfully for years. But I added more: https://github.com/perl11/cperl/blob/master/pod/perlcperl.po... The .git/cache is a submodule, so others can easily rebase also. And a lot of helper scripts to rebase and pull --rebase all work branches automatically. All current branches are constantly rebased to master, others default to pull --rebase (aliased to lb), with the shared. git/cache there are no conflicts for years. I'm also doing this for several forks automatically, like adding patches and CI smokes to popular repos like clisp, libffi, openssl, pcre2, coreutils and many more. These are rebased hourly, conflicts appear maybe once a year.

No, 9.2 still broken for me. The strlen and strncpy fixes were obviously not enough. https://github.com/perl11/cperl/commit/c0b59c82b053a3434cf3c...

Oh my, it misses the point completely. The problem is the automatic call of methods of arbitrary classes, controlled by the external YAML, such as DESTROY. unblessing after loading does not help at all. You need to disallow blessing during load, or provide a whitelist, such as python does. cperl's YAML library does contain the security fixes for some years already: https://github.com/perl11/cperl/blob/master/cpan/YAML-LibYAM..., the cpan version maintained by this person is still vulnerable, besides being incompatible to itself, and unusable for cpan. https://github.com/rurban/yaml-libyaml-pm/tree/safe contains the whitelist variant, as in python.

I wouldn't call it impressive. 2 months too late, too many bugs, horrible security, not much improvements, still doing more destruction than good. Compare it to the "non-community" professional effort https://github.com/perl11/cperl/releases/tag/cperl-5.26.0 http://perl11.org/cperl/perl5260cdelta.html regular expressions are much better with pcre2, which almost work (50% faster) with https://metacpan.org/pod/re::engine::PCRE2

> In Evan’s keynote, he proposed a really interesting and ambitious solution to the problem he called “lifting the core.” It involved shipping Ruby with LLVM intermediate representation of the CRuby functions to allow the LLVM JIT technology to look inside the CRuby functions and dramatically increase the optimization horizon. As far as I know, this hasn’t been attempted yet — although, if it has, I really want to see it! Actually unladen_swallow and cperl are doing this. Compile the whole runtime to a lib<rt>.bc (trivial make rule), load this bitcode file (a single call), and add the expensive optimizations, esp. the inliner and IPO in llvm. Just the type-checks need to be done in the jit. This inliner does a lot of good magic esp. for the small RT functions. >10x faster. The compiler is expensive though (i.e. very slow), and LLVM change

> Rust code that type-puns an unaligned pointer into an integer would crash on MIPS or SPARC just like the C code would. Actually you can enforce that on Intel too. I do that for some hash functions in debugging mode, to avoid valgrind slowdown. e.g. https://github.com/perl11/cperl/blob/master/cpan/Digest-MD5/... #if defined(U32_ALIGNMENT_REQUIRED) && defined(__GNUC__) && (defined(__x86_64__) || defined(__i386)) /* Generate SIGBUS on unaligned access even on x86: Set AC in EFLAGS. See http://orchistro.tistory.com/206 Also see https://sourceforge.net/p/predef/wiki/Architectures/ for possible other compilers. Here only GNU C: gcc, clang, icc. MSVC would be nice also. */ #ifdef __x86_64__ __asm__("pushf\n" "orl $0x40000, (%rsp)\n" "popf");

Interestingly Emacs is not the only project affected by this glibc/dumper dispute. I added the stone-old patches for perl to my cperl fork, to be able to dump/compile perl scripts to native binaries the fast way. Improved dumpers are here: https://github.com/perl11/cperl/commits/feature/gh176-unexec Mostly unified error handling and a few darwin segment instabilities. It is very fragile to use with a static library, but ok as dynamic library. Emacs uses the dumper in the main exe, not in a library. Solaris is the easiest to use. So I know a little bit of the troubles they are talking about here. Dan's portable dumper would be nice to have, XEmacs had this decades ago, but it never made it over to Stallman emacs. Wonder why :) So looking at the new pdump, it really is horrible. I don't think I want to do that. I'll rather add a proper stat

I worked with this recently. This feature is not a nightmare, just because the author doesn't understand what a linker does, and the necessary separation of old and new dynamic memory. It's rather a stable and very useful feature, which just recently got under attack, because glibc doesn't want to maintain malloc_get_state() / malloc_set_state() anymore. XEmacs has a portable dumper pdump, which is a hack compared to emacs unexec. See https://lwn.net/Articles/673724/ and esp. https://lwn.net/Articles/673815/ I recently re-added unexec support (i.e. native compilation) to perl5 in my cperl fork, but I haven't got it stable yet. Super trivial on solaris, but not so easy on elf, darwin and windows with its various compilers and the different way to treat their segments. But it's still the easiest way to do it, compared to pdump or a seperate