https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #14 from Rachel Mant ---
(In reply to Andrew Pinski from comment #12)
> Let me try again to show the exact events of why I think this is not a
> libstdc++/GCC bug here.
>
>
> time thread/core 1 thread/cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
Rachel Mant changed:
What|Removed |Added
CC||rachel at rachelmant dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
--- Comment #7 from Rachel Mant ---
Continuing to think on this a bit, and.. if it is undefined behaviour as you
say, then granted this is not a bug on ASAN/TSAN.. but it is still a bug as
UBSAN does and says nothing when faced with this even tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
--- Comment #6 from Rachel Mant ---
Ok, fair enough - though I'd like to know your thoughts then on the rest of the
f*open() family and the fact the sanitizers do check for nullptr
paths/filenames even though the wording is the same. The fopen64(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
--- Comment #4 from Rachel Mant ---
Glibc, MSVCRT and other CRTs all check for this condition in userspace and NOP
it by short-circuiting the call with a return of nullptr. MSVCRT even documents
this
(https://docs.microsoft.com/en-us/cpp/c-runtim
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rachel at rachelmant dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc
