Merged as 3b28a8f0! Thanks for the tests, too.

Thanks for reaching out, Benjamin. Sharp of you to notice that!

Note that my article says its "focus is entirely extended assembly, and 
not basic assembly." That std asm is a basic assembly block and so "has 
different rules." No constraints means no special case to consider. Review 
is more basic, "Will this blunt tool behave appropriately here?" instead 
of subtler issues with constraints and volatile. Note how the top-level 
basic asm blocks in the tests are also not explicitly volatile.

Thanks! I grepped my own system and found Cflags.private, too. But when I 
compared outputs to pkgconf it didn't match. Neither did freedesktop.org. 
They both output Cflags of private packages, and u-config was not due to 
the recent 62c88c08 (ignore missing private packages). In fact, they both 
disagree with one of your new test outputs. So I also reverted 62c88c08, 
which required changing that expected test output.

A quick test you can see for yourself, freedesktop.org or any version of 
pkgconf, "a.pc":

    ...
    Requires.private: b

And "b.pc":

I was testing straight from the repository, not my system's pkg-config. I 
dug a little further, and it turns out it's not because my pkgconf is too 
old but too new. As of pkgconf 2.4.0, specifically a79952a (2025-02-02), 
your example produces an error. So they went the opposite direction from 
your change.

(Unfortunately it's difficult to test directly due to botched fgetline 
changes in d0f8f3f which introduced a buffer overflow. All commits from 
that until 88258bd crash for me. 88258bd doesn't fix the overflow, which 
as far as I can tell, is still present as of pkgconf 2.4.3. It merely 
reduced occurrence to specific large inputs rather than any input.)

Thanks for the background info.

> sniff out a u-config bug all things considered

Was this actually a bug, though? I just checked, and neither pkgconf nor 
Freedesktop.org pkg-config ignore missing Requires.private packages. The 
new behavior is more like a feature, allowing builds to go forward even 
when unneeded information is missing. As for which is most correct, old or 
new behavior, I think it could be reasonably argued either way.

Thanks, NRK! At first I thought this might have been a regression from 
recent changes, but soon realized it's not. So what prompted this now? A 
real world situation?

I merged it, but made a couple of minor tweaks:

* Moved static_ onto processor. That's where similar options live. It's a 
little awkward using it outside a "processor" context at the bottom, but 
oh well. (Now that it's no longer concerned with parsing, perhaps I should 
rename it to "loader" because it loads packages.)

* Wrapped package names in single quotes in MATCH. Otherwise "e" trivially 
matches 'e' in "package" in the error message. In the new error message 
tests I deliberately chose names that would never appear as substrings

Good question. I hadn't investigated when I wrote the article, and I still 
didn't know the specifics when I saw your message here. Investigating the 
segfault in GDB, I found that all my counted strings initialized with null 
pointers. It smelled like a PIE issue, and the problem went away when I 
disabled PIE at link time.

But I got to the bottom of it! For the sake of those following along, a 
u-config string is a 16-byte header: a pointer-length tuple. After macro 
expansion, initialization looks like:

    s8 example = (s8){"example", sizeof("example")-1};

OpenBSD Clang puts a copy of `example` in relro / rodata. To initialize, 
Clang copies it onto the stack with a movups load and movaps store (good

All merged, thanks, NRK!

Before looking, I was concerned your changes would set pc_path to a static 
string on Windows as well, but you correctly kept the pkg-config.exe path 
as the "compiled-in" string, which is the appropriate, analogous behavior. 
In its original context, pkg-config, and the toolchain sysroot in general, 
are not designed to be relocatable, unlike a "portable" Win32 application. 
(Kind of a shame, because it would be useful if I could install, say, .deb 
packages into "$HOME/.local/" as a regular user.)

Thanks for digging this up, NRK. I hadn't taken time to investigate, and 
there's more to it than I expected. Looks like Gentoo has been patching 
this since February 2011 with Readline 6.2.

If ELF had something like DEF files, the packager could list a complete, 
clean interface in a DEF file, then include it at link time (e.g. via LIBS 
or whatever). It would set the entire public surface area of the library, 
hiding all the internal functions it exposes, without touching the code, 
which in the case of Readline otherwise defines no "RL_API" prefix macro 
to control custom visibility/dllexport attributes of API symbols. A DEF 
can even rename symbols, so a packager could prepend a namespace prefix to 
the exported name without macro hacks:

LIBRARY libreadline8

Thanks for the kind words, Antonin, and I'm happy to hear that!

> Am I correct in understanding that the two types of files are identical 
> (regardless of the extension)?

Yup, it's no more than a difference in naming convention, and these are 
the same format. I've added a brief note about this to my article. I do 
think the Mingw-w64 convention is better, but it wouldn't have worked on 
the old 8.3 filesystems where the MSVC conventions originated.

> You suggest generating import libraries with mingw for compatibility 
> with MSVC.

My views have shifted since writing my article 4 years ago. Not only have