libredwg VS libu8ident

I have a much better and oracti al solution: https://github.com/LibreDWG/libredwg/blob/7d9fc3da44bbdb60a4...

free is way too slow if not needed, so detect valgrind via its API. Just on valgrind to the unnecessary free dance. ASAN's memleak detector is disabled via its env.

Perl5 does its final destruction similarly, only when it has important destructors (like IO, DB handles and such) to call.

Now even for your local github action:

https://github.com/LibreDWG/libredwg/blob/master/.github/wor...

Behind the scenes we’re using the open source LibreDWG library to run a number of AutoCAD native commands such as DATAEXTRACTION.

I use it for reverse engineering unknown struct layouts for DWG classes. A field packing problem.

I'm using picat, a better Prolog dialect, and generate the facts automatically from C to generate the field layouts via picat automatically.

https://github.com/LibreDWG/libredwg/blob/master/examples/AC...

optimization problems as in compilers are extremely natural in Prolog.

In programming languages it's much worse. Identifiers can either be unidentifiable, and if so everybody has a different opinion what "identifiable" means. Even the standard on identifiers, UTF-39, is buggy and has too many interpretations, leading to a complete disaster. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

In punycode domain names it's quite simple still.

With other names, it's even worse. No-one cares. Linkers do not, username and filesystem drivers do not. The Apple HFS+ did care a bit one day, until someone in the higher ranks decided that no-one needs unicode security anymore and switched the new APFS to unsafe again.

No, it's definitely not safe to use unrestricted Unicode in a compiler. See https://github.com/rurban/libu8ident/ for identifier rules, and http://www.unicode.org/reports/tr55/ for much worse problems.

That's why unicode published the security guidelines and mechanisms to avoid such attacks. In 2004 already.

The problem is that nobody cared. Browsers invented punycode instead of following tr39, email ditto. But ok, at least something. Java did it, cperl did, rust did it.

Everybody else is vulnerable. Esp. most other programming languages, filesystems and login systems. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

I'm maintaining such a library.

coreutils, diff, grep, patch, sed and friends all cannot find Unicode strings, they have no string support. They can only mimic filesystems, finding binary garbage. Strings are so rthi g different than pure ASCII or BINARY garbage. Strings have an encoding and are Unicode.

Filesystems are even worse because they need to treat filenames as identifiers, but do not. Nobody cares about TR31, TR39, TR36 and so on.

Here is an overview of the sad state of Unicode unsafeties in programming languages: https://github.com/rurban/libu8ident/blob/master/c11.md