https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #16 from andysem at mail dot ru ---
Thanks for the fix. And for the explanation.
Yes, backport would be nice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #15 from Jonathan Wakely ---
Fixed on trunk, but this code has been present since 2003 so I want to backport
it to all active branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #14 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:498f9aefbf36b0e3f119d634c41d86699ce6fed2
commit r15-5718-g498f9aefbf36b0e3f119d634c41d86699ce6fed2
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #12)
> Overflow is possible though. If you call it with max = (-1ull / 4 + 2) then
> the alloca length will be 4. If (from_end - from) requires more than 4 wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #12 from Jonathan Wakely ---
Overflow is possible though. If you call it with max = (-1ull / 4 + 2) then the
alloca length will be 4. If (from_end - from) requires more than 4 wide
characters, we'll overflow the alloca buffer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #10 from Jonathan Wakely ---
(In reply to andysem from comment #0)
> The problem appears to be that std::codecvt< wchar_t, char, std::mbstate_t
> >::do_length() accesses characters outside the [s, s + max_size) range,
I'm pretty sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #7 from andysem at mail dot ru ---
Reproduces for me:
$ g++ -g2 -O0 -o codecvt_length_bug codecvt_length_bug.cpp
$ ./codecvt_length_bug
*** buffer overflow detected ***: terminated
Aborted (core dumped)
$ g++ -v
Using built-in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #8 from andysem at mail dot ru ---
I think, sanitizers won't detect it unless you build libstdc++ with them
enabled. I would expect valgrind to detect it though.
I think, Ubuntu builds libstdc++ with _FORTIFY_SOURCE enabled, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #6 from Jonathan Wakely ---
I can't reproduce a crash, or any runtime error from valgrind, ubsan, asan, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #5 from Jonathan Wakely ---
You can click on the "Keywords" link to see the meanings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #4 from Sam James ---
It means "GCC (in some form) generates incorrect code for a valid testcase".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #3 from andysem at mail dot ru ---
I'm not sure about the meaning of the wrong-code keyword, but just to clear, I
do not consider the code sample in the bug report to be wrong (i.e. incorrect
usage of the standard library). If it is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #2 from andysem at mail dot ru ---
> outside the [s, s + max_size) range
This should be [from, from_to) range. Sorry, posted a little too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #1 from andysem at mail dot ru ---
Created attachment 53089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53089&action=edit
Test case to reproduce the problem.
17 matches
Mail list logo
