[Bug libstdc++/112100] ubsan: misses UB when modifying std::string's trailing \0

2023-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> It would need a completely new category of "memory location that you can
> read and write to but nothing else"

That was supposed to say "read and write zero to but nothing else".

[Bug libstdc++/112100] ubsan: misses UB when modifying std::string's trailing \0

2023-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Maybe some how libstdc++ debug mode can catch this
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/manual/manual/
> debug_mode_using.html#debug_mode.using.mode
> -D_GLIBCXX_DEBUG

Only by adding a "past-the-end character is still null" check to std::string
member functions (which ones, all of them? Just accessors that would let you
read the null, like c_str, operator[], data etc.?)

That would be doable, but sounds pretty expensive.

[Bug libstdc++/112100] ubsan: misses UB when modifying std::string's trailing \0

2023-10-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jan Engelhardt from comment #0)
> ==55843==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xsomething

How would that even be possible? The terminating nul clearly has to be in
allocated memory, because you are allowed to read it. So asan can't treat it as
overflow. It's valid memory. Not only that, it's valid *writable* memory. You
are allowed to store '\0' there.

It would need a completely new category of "memory location that you can read
and write to but nothing else". That's not an asan or ubsan check.

> https://eel.is/c++draft/string.access specifies the modification of the NUL
> char's position to values other than \0 is UB, so it should warn about this.

There are hundreds of things the standard says are undefined that asan and
ubsan can never detect. It's unreasonable to expect it IMHO.

[Bug libstdc++/112100] ubsan: misses UB when modifying std::string's trailing \0

2023-10-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100

Andrew Pinski  changed:

   What|Removed |Added

  Component|sanitizer   |libstdc++

--- Comment #1 from Andrew Pinski  ---
Maybe some how libstdc++ debug mode can catch this
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/manual/manual/debug_mode_using.html#debug_mode.using.mode
-D_GLIBCXX_DEBUG