Repository navigation
MSVC: error C4789: in function 'main' buffer '' of size 12 bytes will be overrun; 8 bytes will be written starting at offset 11 #2099
Description
Compiling the code below with latest MSVC (cl 19.51.36244) and the flags -std:c++20 -MD -O2 -Zc:__cplusplus -Zc:preprocessor -sdl gives the error:
include\stdexec\__detail\__basic_sender.hpp(443) : error C4789: in function 'main' buffer '' of size 12 bytes will be overrun; 8 bytes will be written starting at offset 11
It might be a false positive but I'm not sure and thought it might be worth reporting.
BTW: It's an error only because of -sdl and can be downgraded back to a warning with /w14789
#include <stdexec/execution.hpp>
using namespace stdexec;
auto main() -> int {
auto work = just() | let_value([] { return just(); });
sync_wait(just(uintptr_t{0})
| let_value([unused_capture = 0, unused_capture2 = work](uintptr_t /*unused_value*/) { return just(); }));
}
Activity
alwaysprince05 commentedon Oct 13, 2026
The code at the reported location has been substantially reworked on main since this was filed:
__basic_sender.hppwas last touched by857bc438("give up mangling tparams of__sexpr", Oct 8) and the file is now 416 lines — line 443 from the diagnostic no longer exists in the current file, so the exact offending code may be gone.I don't have an MSVC 19.51 environment to test with, so I can't confirm whether the diagnostic still fires on current main. If anyone has a recent MSVC handy, running the snippet from the report against current main would settle whether this is still relevant — otherwise it may be a stale diagnostic (it's only an error because of
-sdl, downgradable with/w14789as noted in the report).KassaSana commentedon Oct 28, 2026
I reproduced this on current main with MSVC 19.50. The diagnostic still occurs, now in
__let.hpp:519.I narrowed it down to a standalone repro that suggests an MSVC
[[msvc::no_unique_address]]layout bug. ASan confirms a stack-buffer-overflow, and I also reproduced silent data corruption without ASan.Disabling the attribute on MSVC resolves the issue. I have a patch with a regression test that fails before the fix and passes afterward. All 1,104 tests pass with the patch under MSVC + ASan.
The tradeoff is increased object sizes on MSVC. Would maintainers be comfortable with disabling the attribute again, or would you prefer a narrower workaround?
alwaysprince05 commentedon Oct 28, 2026
Thanks for tracking that down — that settles the staleness question I raised, and the reduced repro is a lot more useful than the original report.
Some context that may help the maintainers' call on the tradeoff: the attribute really was disabled on MSVC once before.
4ccd7534(Sep 2023) commented it out as "MSVC: Disable [[msvc::no_unique_address]] due to incorrect codegen", and left the MSVC bug report in the comment above the define (developercommunity.visualstudio.com/t/Incorrect-codegen-when-using-msvc::no_/10452874). It's since come back behind a version gate in__config.hppthat falls back only forSTDEXEC_MSVC_VERSION < 1943, so 19.50 and 19.51 both get the attribute today.One more data point for the decision: the Windows CI jobs already run under ASan —
test-windows.ps1configures every cl job with-DCMAKE_CXX_FLAGS="/fsanitize=address /EHsc", on the 14.43/14.50 toolset lines inci.cpu.yml. The suite is green on unpatched main despite the runtime corruption you reproduced without ASan, so nothing in the current test payloads trips it (or MSVC's ASan doesn't see it), and C4789 only escalates to an error under-sdl, which CI never passes. So on the toolchain family your 19.50 repro targets, nothing in current CI signals the bug.For what it's worth I'd lean toward disabling it globally again, same as 2023, and re-gating only after Microsoft actually fixes it — but that's the maintainers' size-vs-soundness call.
One practical suggestion for whatever PR comes out of this: it would be good to confirm the regression test also fails on unpatched main under the configuration CI actually uses (the
/fsanitize=address /EHscflags fromtest-windows.ps1), so the Windows matrix catches the regression from the first failing CI run. Happy to review the patch once it's up.KassaSana commentedon Oct 29, 2026
Thanks for the context! Addressed #2383 with the MSVC workaround and regression test.
Confirmed the new test fails on unpatched
mainin both Debug and Release using MSVC 19.50 with/fsanitize=address /EHsc. With the fix, all 1,106 tests pass in both configurations.Preciate the context :)
ericniebler commentedon Oct 31, 2026
@KassaSana writes:
has this bug been reported to microsoft? this issue has been closed as fixed.
MSVC: disable [[msvc::no_unique_address]] due to incorrect codegen
ericniebler commentedon Nov 1, 2026
@mika-fischer can you tell me if there is a compiler bug report for this?
mika-fischer commentedon Nov 2, 2026
I did not report this anywhere else than here since I was unsure what the root cause was.
KassaSana commentedon Nov 3, 2026
No, it hadn't been reported. I filed it here: https://developercommunity.visualstudio.com/t/msvc::no_unique_address:-non-empty-m/11177564
I narrowed it down to a 30-line repro that doesn't depend on stdexec. On 19.50, a
[[msvc::no_unique_address]]uint64_tmember gets placed at offset 0, on top of another member, and the class gets 4-byte alignment. It looks like 10452874 either came back or never covered this case. Once there's a fixed compiler version we can put the version gate in__config.hppback.