Notices by keithp (keithp@fosstodon.org)

It's a silly way to write dates, but it does offer us a unique opportunity. Happy τ/2 day to all who celebrate.

@llvm @pinskia @amonakov I dunno, it's a tough race between implementation-defined behavior and undefined behavior. Both are unpardonable defects of any language, but the C standard embraces them as features?

@paulmckrcu nolibc is awesome and you know it.

@etchedpixels @dalias yeah, gcc converts printf("hello world\n") into puts("hello world");

That's one of the numerous optimizations present in "hosted" mode, which is why I always tell people to get rid of -ffreestanding when building with a full C library.

Btw, on armhf, hello world is way smaller than on x86_64:

$ size test-hello-armhf
text data bss dec hex filename
1520 76 4624 6220 184c test-hello-armhf

You know how I always say picolibc isn't a Linux C library because it doesn't do all of the fancy Linux stuff? Well, it turns out you don't need much to get a semi-functioning system.

$ size test-hello-picolibc test-hello-glibc
text data bss dec hex filename
3632 144 4656 8432 20f0 test-hello-picolibc
645697 23704 22576 691977 a8f09 test-hello-glibc

I blame Kees Cook for nerd-sniping me on this one.

https://github.com/picolibc/picolibc/tree/native-linux

picolibc has been reformatted with clang-format. All PRs will now be checked to make sure they are formatted correctly, so any pending requests will need to be fixed and resubmitted. I'm looking forward to having only one coding style to deal with.

Thanks to all of the picolibc contributors over 2025 and best wishes for 2026.

Almost home from #debconf25 -- a long trip, but well worth it. I feel exhausted and refreshed.

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...