bemanproject / expected / 39199637006

98%

Build Type

push

github

Committed by web-flow

Commit Message

Quiet gcc's ASan -Wmaybe-uninitialized false positives in expected<void, E> (#104)

gcc's `-fsanitize=address` build reports `-Wmaybe-uninitialized` on
reads of `unex_` in value-state `expected<void, E>` objects. Every
report is a false positive, since `has_val_` guards each read exactly.
They were 43 of the 44 warnings in the default Asan build with gcc 15.

- **Fix at the source.** Give the union an empty `struct {} void_;`
alternative and initialize it in every constructor that can end in the
value state, as libstdc++'s `expected<void, E>` does. The member is
unmarked, so specgen leaves it out of the synopsis. Its rationale sits
after the class body, because a comment inside the union would be
carried into the synopsis.
- **Move the remaining suppression.** The gcc-14/15/16 toolchain files
each added `-Wno-maybe-uninitialized` to the Asan flags, but the default
toolchain and gcc-12/13 did not. A plain `make` warned 44 times where
`make TOOLCHAIN=gcc-16` was clean. The suppression isn't version-gated,
so it now lives in `gcc-flags.cmake`. It's still needed for
`expected<T&, E>`, whose value constructor stores a runtime address, so
the same folding can't apply.

gcc-16: 1249/1249 tests pass.

The generated wording is unchanged. I checked that by regenerating it
with specgen 0.4.0 on top of this branch. Earlier specgen releases could
leak `void_;` into the `expected<void, E>` synopsis once this member sat
beside the `\omit`ted copy assignment from #100
(steve-downey/specgen#147), so regenerate with 0.4.0 or later.

Coverage Stats

1 of 1 new or added line in 1 file covered. (100.0%)

21 existing lines in 1 file now uncovered.

829 of 850 relevant lines covered (97.53%)

22.91 hits per line