|
From: Janko S. <jan...@ec...> - 2025-10-23 13:42:56
|
Note: https://rurban.github.io/libu8ident/ "Packaging Recommended is to use the static lib or sources with your known normalization, profile and xid options. E.g. via cmake or submodule integration. Because the size and run-time varies wildly between all the possible and needed options, and this is in the hot path of a parser. A shared library needs to provide all the options at run-time, i.e. empty configure options." But also note "E.g. via cmake or submodule integration" Hopefully it can be done simpler. Also Ruby: "Build dependencies: ronn (dnf install rubygem-ronn-ng)" It seems it's worth attempting, at least. --- Ursprüngliche Nachricht --- Von: Philipp Klaus Krause <pk...@sp...> Datum: 23.10.2025 13:06:43 An: sdc...@li... Betreff: Re: [sdcc-devel] Using libunistring in SDCC? Am 23.10.25 um 10:37 schrieb Philipp Klaus Krause: > * Regarding the security implication of unicode (e.g. homoglyph > attacks); Having the normalization and the checks for valid identifiers > does help here. C23 is safer than C11 was (which AFAIK allowed more > unicode in identifiers). > But for a full solution we'd have to do more (N2932, rejected for C2y, > but WG14 wanted it as TS, which so far didn't happen), but AFAIK, > currently libraries that implement everything we'd want for security are > not that widespread (they exist, in particular libu8ident, but I don't > think many distros package them). Though, since we'll do the configure time check anyway, we could go for libu8ident instead of libunistring. That would give more security in builds that have the library. But fewer builds would have the library, since it is far less common. I guess we could link against a static libu8ident library, so there'd be no run-time dependency, at least? Philipp _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |