public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios.
@ 2022-03-28 9:12 chumarshal at foxmail dot com
2022-03-28 9:17 ` [Bug c++/105077] " redi at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: chumarshal at foxmail dot com @ 2022-03-28 9:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
Bug ID: 105077
Summary: The std::bad_array_new_length is not thrown for some
new array scenarios.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chumarshal at foxmail dot com
Target Milestone: ---
The std::bad_array_new_length is not thrown for the following three scenarios.
These scenarios do not follow C++ spec:"std::bad_array_new_length is the type
of the object thrown as exceptions by the new-expressions to report invalid
array lengths if array length is negative."
case1 using g++ -O0
==========================================================================
#include <new>
#include <stdexcept>
int main()
{
try
{
int negative = -1;
new char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
case2 using g++ -O0
==========================================================================
#include <new>
#include <stdexcept>
struct s_char
{
char ch;
};
int main()
{
try
{
int negative = -1;
new s_char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
case3 using g++ -O0
==========================================================================
#include <new>
#include <stdexcept>
struct s_char_with_new
{
char ch;
void *operator new[] (std::size_t sz)
{
abort();
}
};
int main()
{
try
{
int negative = -1;
new char[negative];
}
catch(const std::bad_array_new_length &e)
{
}
return 0;
}
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
@ 2022-03-28 9:17 ` redi at gcc dot gnu.org
2022-03-28 9:21 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-28 9:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Looks like a dup of PR 85795
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
2022-03-28 9:17 ` [Bug c++/105077] " redi at gcc dot gnu.org
@ 2022-03-28 9:21 ` redi at gcc dot gnu.org
2022-03-28 9:47 ` chumarshal at foxmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-28 9:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've added the first example there. The other two examples are exactly the same
scenario.
*** This bug has been marked as a duplicate of bug 85795 ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
2022-03-28 9:17 ` [Bug c++/105077] " redi at gcc dot gnu.org
2022-03-28 9:21 ` redi at gcc dot gnu.org
@ 2022-03-28 9:47 ` chumarshal at foxmail dot com
2022-03-28 10:34 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: chumarshal at foxmail dot com @ 2022-03-28 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #3 from marshal <chumarshal at foxmail dot com> ---
(In reply to Jonathan Wakely from comment #2)
> I've added the first example there. The other two examples are exactly the
> same scenario.
>
> *** This bug has been marked as a duplicate of bug 85795 ***
But why "new int[negative];" throws std::bad_array_new_length as following
case?
I think "new int[negative]" and "new char[negative]" should both throw
std::bad_array_new_length when "int negative = -1;".
new int[negative]
==========================================================================
#include <new>
#include <stdexcept>
int main()
{
int negative = -1;
new int[negative];
return 0;
}
terminate called after throwing an instance of 'std::bad_array_new_length'
what(): std::bad_array_new_length
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
` (2 preceding siblings ...)
2022-03-28 9:47 ` chumarshal at foxmail dot com
@ 2022-03-28 10:34 ` redi at gcc dot gnu.org
2022-03-30 1:52 ` chumarshal at foxmail dot com
2022-03-30 8:59 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-28 10:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to marshal from comment #3)
> But why "new int[negative];" throws std::bad_array_new_length as following
> case?
Because that case requires size_t(-1) * sizeof(int) and the compiler detects
that it's out of range. It fails to detect that size_t(-1) is already
incorrect.
> I think "new int[negative]" and "new char[negative]" should both throw
> std::bad_array_new_length when "int negative = -1;".
Yes, it's a bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
` (3 preceding siblings ...)
2022-03-28 10:34 ` redi at gcc dot gnu.org
@ 2022-03-30 1:52 ` chumarshal at foxmail dot com
2022-03-30 8:59 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: chumarshal at foxmail dot com @ 2022-03-30 1:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #5 from marshal <chumarshal at foxmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to marshal from comment #3)
> > But why "new int[negative];" throws std::bad_array_new_length as following
> > case?
>
> Because that case requires size_t(-1) * sizeof(int) and the compiler detects
> that it's out of range. It fails to detect that size_t(-1) is already
> incorrect.
>
> > I think "new int[negative]" and "new char[negative]" should both throw
> > std::bad_array_new_length when "int negative = -1;".
>
> Yes, it's a bug.
Please modify "Status:RESOLVED DUPLICATE of bug 8579", because it's a new bug
and it's not same with bug 8579.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/105077] The std::bad_array_new_length is not thrown for some new array scenarios.
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
` (4 preceding siblings ...)
2022-03-30 1:52 ` chumarshal at foxmail dot com
@ 2022-03-30 8:59 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-30 8:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105077
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's the same. In both cases the compiler fails to check if the size expression
is erroneous, and calls operator new(n) with a bad value that causes a
std::bad_alloc exception. I'm both cases, the compiler should be checking the
expression first and throwing the correct exception.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-03-30 8:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-28 9:12 [Bug c++/105077] New: The std::bad_array_new_length is not thrown for some new array scenarios chumarshal at foxmail dot com
2022-03-28 9:17 ` [Bug c++/105077] " redi at gcc dot gnu.org
2022-03-28 9:21 ` redi at gcc dot gnu.org
2022-03-28 9:47 ` chumarshal at foxmail dot com
2022-03-28 10:34 ` redi at gcc dot gnu.org
2022-03-30 1:52 ` chumarshal at foxmail dot com
2022-03-30 8:59 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).