One can call it a dark and dusty corner of the toolchain. The user is not expected to pull away the cobwebs and peer around.
If you use nm to look in the libc.a of the Arm toolchain, you won't find the regex object files in there. I tried the top level libc.a in the Arm toolchain directory that I have, the object files are not in there. But there is an rpmatch.o that references them, so it really is a very dusty corner...
To compare, I took the Cygwin libc.a and the regex object files are present.
The C regex header looks like the classic Henry Spencer thingy, see this directory on the newlib mirror:
https://github.com/bminor/newlib/tree/m ... libc/posix
The bulk of the regex implementation is in regcomp.c, and available to compiled programs since it is in libc.a. It just isn't compiled into arm-none-eabi. Presumably adding a standalone Henry Spencer regex source file set (well, everybody uses it as a baseline) into your program, tweak the makefiles, make it non-POSIX usable etc, and the regex stuff that you coded should work the same.
If you use nm to look in the libc.a of the Arm toolchain, you won't find the regex object files in there. I tried the top level libc.a in the Arm toolchain directory that I have, the object files are not in there. But there is an rpmatch.o that references them, so it really is a very dusty corner...
The C regex header looks like the classic Henry Spencer thingy, see this directory on the newlib mirror:
https://github.com/bminor/newlib/tree/m ... libc/posix
The bulk of the regex implementation is in regcomp.c, and available to compiled programs since it is in libc.a. It just isn't compiled into arm-none-eabi. Presumably adding a standalone Henry Spencer regex source file set (well, everybody uses it as a baseline) into your program, tweak the makefiles, make it non-POSIX usable etc, and the regex stuff that you coded should work the same.
Statistics: Posted by katak255 — Tue Oct 28, 2025 11:04 pm