[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85435

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.3
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
I fixed this in r267651 for PR 87787

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85435

--- Comment #2 from Jonathan Wakely  ---
The library will never call it with a null pointer, but users could do. Not
many people use char_traits directly though. Probably even fewer use the
primary template, because there are specializations for char, wchar_t, char16_t
and char32_t which were already fixed for PR 65049.

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85435

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This isn't important to fix just because ubsan will be happy, but the
optimizers actively derive non-NULL range for the pointers from the memmove
call and so could optimize away say comparisons against NULL of those pointers
etc.
So, if it is valid for the move method on char_traits to be called with NULL,
the fix is very important.

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85435

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65049
 Ever confirmed|0   |1