| 13 Feb 2026 |
 emily | so libcxxhardeningfast is just a nop | 03:30:04 |
|  hoplopf joined the room. | 10:25:27 |
 ris_ | hmmmmmmmmmmmm | 21:51:10 |
| ris_ | well.. open to opinions. i should at least update the documentation to correspond to reality | 21:51:54 |
| emily | I like hardening, but I'm also okay with us matching the platform default here | 22:20:08 |
| emily | not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 | 22:20:30 |
| ris_ | i fear the latter | 22:33:54 |
 Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 I sure am monitoring nix perf :) glibcxx assertions absolutely tank inlining in the parser | 23:54:31 |
| emily | I don't think that cleanly maps to libc++ hardening though | 23:55:00 |
| emily | (and probably ~nobody is using Nix with libc++ on Linux) | 23:55:14 |
| Sergei Zimmerman (xokdvium) | I think glibcxx assertions are roughly second level libc++ hardening. At least that’s what meson enables with n_debug | 23:56:14 |
| Sergei Zimmerman (xokdvium) | In my experience the overhead is enough to necessitate disabling hardening for some translation units that are just too hot and aren’t security sensitive | 23:57:38 |
| emily | second level = fast (numeric value 2) or extensive? | 23:58:24 |
| emily | because macOS upstream default is fast so we certainly wouldn't go below that OOTB | 23:58:31 |
| emily | would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway | 23:59:07 |
| emily | (but controlling for version might be hard?) | 23:59:12 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
because macOS upstream default is fast so we certainly wouldn't go below that OOTB As in the llvm toolchain enables that by default? | 23:59:13 |
| 14 Feb 2026 |
| emily | yes:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config_site
43:#define _LIBCPP_HARDENING_MODE_DEFAULT 2
| 00:00:26 |
| emily | (2 is fast) | 00:00:29 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway Hm, I guess the only way to tell is to benchmarking :) I could see about how that would affect nix itself. Undefing the flag should be easy enough | 00:05:09 |
| ris_ | i'm going to prepare a PR to switch back to fast | 11:04:39 |
| ris_ | this does make me wonder how libcxxhardening* should interact with _LIBCPP_HARDENING_MODE_DEFAULT though | 11:30:03 |
| ris_ | https://github.com/NixOS/nixpkgs/pull/490358 | 12:07:04 |
| emily | IMO we should just control the default with that rather than with wrapper flags. though on macOS we are not building libc++ anyway | 15:52:41 |
| ris_ | interesting - we might have to do some hackery as I wouldn't expect _LIBCPP_HARDENING_MODE_DEFAULT to be designed to be set from the cli | 17:31:34 |
| emily | no I just mean we should set it in our libc++ build :) | 17:58:50 |
| emily | like how we do PIE by default in our GCC and Clang builds | 17:59:13 |
| emily | overriding for an individual package can be flag driven | 17:59:26 |
| emily | though I think NIX_CFLAGS_COMPILE is probably sufficient interface there | 18:00:02 |
| ris_ | i seeee | 18:02:04 |
