Skip to content

libutil++: Include <cerrno> in stringf.cc#2188

Open
kfv wants to merge 1 commit into
freebsd:mainfrom
kfv:lib/libutil++
Open

libutil++: Include <cerrno> in stringf.cc#2188
kfv wants to merge 1 commit into
freebsd:mainfrom
kfv:lib/libutil++

Conversation

@kfv
Copy link
Copy Markdown
Contributor

@kfv kfv commented May 11, 2026

With modern Clang/libc++ and C++20 and later language modes, incidental transitive exposure is being reduced (see Header Removal Policy,) making such dependencies increasingly fragile over time.

This change makes the dependency explicit and aligns the code with the standard library interface model, improving portability across current and future language modes.

No functional or behavioural change intended.

stringf.cc uses errno and related macros without including <cerrno>.

Their availability is guaranteed only when the corresponding header
is included; transitive exposure is implementation-defined.

Modern libc++ has been progressively reducing incidental transitive
includes as part of its header removal policy (see LLVM libc++ Header
Removal Policy and D132284), making such dependencies brittle.

This change includes <cerrno> explicitly to make the dependency
well-defined. No functional or behavioural change intended.

Signed-off-by: Faraz Vahedi <kfv@kfv.io>
@bms
Copy link
Copy Markdown

bms commented May 12, 2026

Thank you for not resorting to the use of "complexity generators" (Dijkstra).

Hmm, didn't know about this LLVM effort. Seems like a subset of: https://include-what-you-use.org/ ; Nothing in-tree is using @bsdjhb -ware <libutil++.hh> but ctld(8) at the moment, so build impact minimal. Most of the stuff in the namespace I'd argue should maybe be done by explicit scope guards, it's just semantic sugar to my eyes which is fine.

(Daniel Stenberg of cURL called out format string sanitization yesterday in his GenAI-assisted security audit announcement, but that's another thing.)

@kfv
Copy link
Copy Markdown
Contributor Author

kfv commented May 13, 2026

We're in the same boat, yeah? ;-D I think contributions tend to turn out better when the tradeoffs are understood and improvements (whether or not valid) stem from an actual need being twigged.

You're absolutely right on the diff herein. The goal is just to remove potential obstacles toward adopting newer C modes over time.

And regarding Daniel's post, I haven't seen it yet, will take a look now, it must be interesting. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants