`gomp_get_uid_for_device` allows ten digits for the `%d`, but `device_num`
is a plain `int`, whose widest rendering is `-2147483648` -- eleven. With
the eight-character `OMP_DEV_` prefix that is twenty bytes plus the NUL into
a nineteen-byte buffer. GCC 16 started noticing, and `libgomp` builds with
`-Werror`:
target.c:5956:31: error: 'snprintf' output may be truncated before the
last format character [-Werror=format-truncation=]
A real off-by-one rather than a false positive, so fix the size instead of
silencing the warning. My first guess was that fortify was to blame, since
the diagnostic named `__builtin___snprintf_chk`; it is not -- turning
hardening off only changes the name in the message.
Co-authored-by: Ben Siraphob <bensiraphob@gmail.com>
Assisted-by: Claude Code (Claude Opus 5)
A release tarball carries generated files that a git tree does not, and
two of those bit us.
`MD5SUMS` is generated when a tarball is rolled. Each sub-source
extractor asserted `[[ -f MD5SUMS ]]` before copying it, so every one of
them failed outright the moment `monorepoSrc` was a git tree:
unpacking source archive /nix/store/...-source
source root is source
<exit 1>
Copy it only when it is there.
The generated sources are the other half: a checkout lacks
`gengtype-lex.cc` and friends, which a tarball ships pre-built, so they
have to be regenerated. Take flex and bison as native inputs when
`fromVCS` says the source is a checkout.
Tarball builds are unaffected either way.
Assisted-by: Claude Code (Claude Opus 5)
