https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Martin Liška changed:
What|Removed |Added
Resolution|--- |MOVED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #8
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 #5 from Jakub Jelinek ---
So it might be well defined on Windows, but unless glibc documents it as an
extension, it is not valid on Linux.
C clearly says: "The fopen function opens the file whose name is the string
pointed to by filen
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
--- Comment #3 from Martin Liška ---
(In reply to Jakub Jelinek from comment #2)
> I think it is undefined behavior and just doesn't crash because the pathname
> is passed to a syscall which will fail then.
> So IMHO nothing we should support.
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
--- Comment #2 from Jakub Jelinek ---
I think it is undefined behavior and just doesn't crash because the pathname is
passed to a syscall which will fail then.
So IMHO nothing we should support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
