Yeah, maybe.
The reference says
> The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system.
My understanding of the vulnerability happens because a different process interleaves access to the same object in the file system between the time of check (TOC) and time of use (TOU) leading to the TOCTOU bug. And this isn't a vulnerability in C++ because it's considered UB by the spec.
I'd be really interested in hearing you explain why this section of the spec isn't relevant to the TOCTOU bug. I'd learn something new if that's the case.
I know you're frustrated by the discussion of CVEs but please understand that the entire article and this thread is based on understanding C and C++'s security record based on CVEs. Herb Sutter compared C++ with Rust, pointing out 61 CVEs in C++ and 6 in Rust. Therefore it's really relevant to compare the attitudes of both communities about filing those CVEs. The fact that the exact same vulnerability warranted a Rust CVE but not a C++ CVE is quite telling.
I'm not happy with the CVE system, no one is. You're not either. All I'm saying is, comparisons of CVEs across languages, like Sutter has done, aren't helpful or useful. He claims that C++ will be equally safe as Rust if CVEs were reduced by 90%. But as long as the C++ community doesn't file CVEs when Rust does, that's not correct. And it's likely to be more incorrect if the community follows through with Herb's suggestion to take control of the CVE filing mechanism.