Notices by keithp (keithp@fosstodon.org)

Finished up the first round of -fsanitize=undefined work in picolibc and wrote down some notes. précis: use this flag, it's good.

https://keithp.com/blogs/sanitizer-fun/

Can anyone explain why glibc's ctype functions return different values than wctype functions in a utf8 locale for Latin-1 Supplement values (0x80 <= c < 0xff)?

isupper(0xc4) == 0
iswupper(0xc4) == 1

Is this correct? How is this motivated by the C standard?

Is it because utf-8 is a multibyte encoding where Ä is represented by two bytes in strings?

Lots of recent picolibc news:

* Oliver Stannard at ARM got testing running on the FVP emulator for more rigorous AARCH64 validation.

* Eduard Tanase fixed a bunch of documentation issues.

* Joel Holdsworth added OpenRisc support.

* Jiaxun Yang fixed my janky tools situation by creating picolibc-ci-tools which auto-builds all of the extra bits we need for CI. They also add LoongArch and LatticeMico32 support. The latter uncovered GCC bugs which I had fun fixing.

Thanks to all of you!

@thesamesam I have no idea when any of the gcc devs will even look at the patch; it's been sitting unloved all year. https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672415.html

Adding uchar.h to picolibc today. Instead of providing useful conversions between UTF-8, UTF-16 and UTF-32, all C23 provides is conversions between those and the awful "multibyte" representations. I can understand why they'd *also* want to connect UTF encodings to the legacy C APIs, but the most important thing we need is a way to validate UTF-8 input which has some pretty tricky corner cases involving missing bytes, overlong encodings, and surrogates. https://github.com/picolibc/picolibc/pull/861

I can't believe I'm still removing K&R function declarations in 2024. https://github.com/picolibc/picolibc/commit/a93d02d88269e6bf22b1e6a5af801c044a7b73de

Released picolibc version 1.8.6 today.
Highlights: ctype avoids a static array, fenv functions are inlined (except on x86).
Full release notes here: https://github.com/picolibc/picolibc/releases/tag/1.8.6

Still having fun with stroked text today. Here's some Lorem Ipsum for y'all.

I also submitted a merge request to the Inkscape Hershey Font extension. In some glorious future Inkscape release, we should be able to draw stroked text with my fun font! I added a bunch more glyphs (Latin Extended-A and a few more) to match the other fonts.

https://gitlab.com/oskay/hershey-text/-/merge_requests/7

First light for gcode-text -- it's driving the new laser cutter Bdale bought and showing the whole font. The Altus Metrum logo below was drawn from an SVG with laser-grbl.

Using meson to run tests on gcode-text found an uninitialized-memory bug in nickle because it *always* sets MALLOC_PERTURB_. Thanks, meson! Bug fixed, and nickle 2.95 released.https://keithp.com/cgit/nickle.git/commit/?id=9ea2939a09be7958cd36c92a9834bea7a9a2e1df

@jmorris and here it is! https://github.com/keith-packard/gcode-text/blob/main/gcode_text.py
It's supposed to be completely compatible with the nickle version.

@jmorris I have to admit I'm tempted to translate this to Python so that other people can use this code for other projects more easily, but Nickle was a much easier target given that the font stuff started in my 'twin' project in C...

My little gcode text drawing program has gotten all fancy with command line arguments and everything.
Did I mention that the stroke font is derived from the Hershey fonts, but with the original curves replaced with cubic splines so that text looks good at a range of sizes? And extended to support ASCII? Bdale also suggested changing the name to 'gcode-text'. Once we get the laser etcher working, I'll upload the package to debian. https://github.com/keith-packard/gcode-text

@kees @jmorris He said "wrong answers only"