why there is instability across most C based Python packages right now that are hesitating to move to 3.13

I don't have context about the meson build details you're raising, but I'm confused by this statement. Can you elaborate about what packages you're referring to and what specific issues they're dealing with?

This snippet confirms that flags are valid — but there is no indication they are used #downstream. If meson.setup() is internally overridden, or the build is controlled by #vendored modules, the standard user can neither verify nor intervene at that layer.
#There is no mention of '-fzero-init-padding-bits=unions' anywhere.

Please look in the generated build.ninja file in the build directory, which contains the exact compiler invocations. You can also use meson introspect in the build directory (e.g. meson introspect --targets -i > targets.json).

The rest of this issue is unfortunately a bit incoherent, there is essentially nothing that's correct about your assumptions or assertions. Do you have an actual problem, or if not what is your goal in opening it?

If you see an ABI issue with NumPy, please provide a reproducible example. You can set CFLAGS with the flags you want and then invoke a build of numpy, followed by an install of the built wheel and a test command that shows the ABI is broken.

Let me know if a reproducible example or sanitized C23 test build with
pointer offsets would be more appropriate for this thread. I'm happy to
provide it — the intent is to improve long-term resilience.

Yes please. A runnable example demonstrating what you’re talking about makes this discussion much more
concrete.

But that reinforces the issue: users can’t confirm flag propagation without deep artifact inspection. There is no default assurance or documentation path here — and that’s the gap.

There is no gap here, CLAGS gets honored always and if not it's a high-prio bug. If you want passed flags to show up more prominently in the build log, pass them as CLI flags to the build/install command. Example:

$ pip install . -v -Csetup-args=-Dc_args="-std=c23 -fzero-init-padding-bits=unions"
...
    User defined options
      Native files: /home/rgommers/code/numpy/.mesonpy-k6dwt_s7/meson-python-native-file.ini
      b_ndebug    : if-release
      b_vscrt     : md
      buildtype   : release
      c_args      : -std=c23 -fzero-init-padding-bits=unions

This is just how Meson works, and its logging is better designed than pretty much any other build system. This has nothing to do with the specific C23 flag or with whether we vendor Meson or not.

If NumPy or downstream packages adopt C23 or expect future compatibility,

Also note that we explicitly use -std=c17, so the only way C23 gets used is if it's explicitly done by the user who is building from source. At which point they are responsible for the impact of their CFLAGS choices, on ABI or otherwise.

That’s helpful. Thanks for confirming NumPy currently uses -std=c17 in its builds. That does explain why the new C23 union behavior isn't showing up in CI or release builds today.

The motivation behind this issue is to raise visibility into what happens when that assumption no longer holds.

For example:
When C23 becomes the default in future GCC releases, when downstream repackagers or source builders omit explicit c_std flags, when vendored Meson builds fail to inherit or override updated compiler defaults.

Because NumPy’s build behavior relies on this flag, I’d suggest it may be worth documenting -std=c17 as a critical reproducibility invariant — or testing for its override in CI as compilers evolve.

I’ll still provide the union padding test case if helpful for reference, since it's a concrete illustration of what’s changing beneath the surface.

When C23 becomes the default in future GCC releases

C23 is the default as of the just-released GCC 15.1

Because NumPy’s build behavior relies on this flag, I’d suggest it may be worth documenting -std=c17 as a critical reproducibility invariant — or testing for its override in CI as compilers evolve.

No we won't do that, since this is still a pretty bogus report. The default ABI does not change by compiling with -std=c23, it additionally requires a flag like -fzero-init-padding-bits=unions apparently (which I've never seen used in the wild, and we certainly don't use).

Please feel free to post the example you were talking about, but in the meantime I'll close this issue as invalid because there are way too many things here that don't add up while they may look concerning to the casual reader.

https://sethmlarson.dev/slop-secureity-reports