public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes
@ 2022-06-13 13:52 dmalcolm at gcc dot gnu.org
2023-06-30 14:39 ` [Bug analyzer/105948] " vultkayn at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-06-13 13:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105948
Bug ID: 105948
Summary: RFE: analyzer could check c++ placement-new sizes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 97110, 105887
Target Milestone: ---
clang's static analyzer has:
https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-placementnewchecker-c
We should check that placement new's memory region is large enough (for both
static and dynamic allocation cases).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
[Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could
implement
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes
2022-06-13 13:52 [Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes dmalcolm at gcc dot gnu.org
@ 2023-06-30 14:39 ` vultkayn at gcc dot gnu.org
2023-09-01 20:06 ` cvs-commit at gcc dot gnu.org
2023-09-01 20:09 ` vultkayn at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: vultkayn at gcc dot gnu.org @ 2023-06-30 14:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105948
--- Comment #1 from Benjamin Priour <vultkayn at gcc dot gnu.org> ---
I'm writing a patch for this, and I've got support for non symbolic bounds.
However, as I wrote my patch, a missing warning came up.
Consider the test case:
---
void var_too_short ()
{
short s;
long *lp = new (&s) long; /* { dg-warning "stack-based buffer overflow" } */
/* { dg-warning "allocated buffer size is not a multiple of the pointee's
size" "" { target *-*-* } .-1 } */
}
void static_buffer_too_short ()
{
int n = 16;
int buf[n];
int *p = new (buf) int[n + 1]; /* { dg-warning "stack-based buffer overflow"
} */
/* (+) */
}
---
In 'var_too_short', two warnings are emitted, second being from
'-Wanalyzer-allocation-size', which makes sense.
Then given the name of this warning, would it not also makes sense to emit it
at (+) in 'static_buffer_too_short' ?
Pointer 'p' is an int, and 'buf' is an array of int, so the buffer size is
indeed a multiple size of 'p'.
However, we know 'p' points to an area actually overflowing 'buf', so
-Wanalyzer-allocation-size is reasonable there.
What are your thoughts on that ?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes
2022-06-13 13:52 [Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes dmalcolm at gcc dot gnu.org
2023-06-30 14:39 ` [Bug analyzer/105948] " vultkayn at gcc dot gnu.org
@ 2023-09-01 20:06 ` cvs-commit at gcc dot gnu.org
2023-09-01 20:09 ` vultkayn at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-09-01 20:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105948
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Benjamin Priour <vultkayn@gcc.gnu.org>:
https://gcc.gnu.org/g:e7b267444045c507654a2a3f758efee5d5b550df
commit r14-3632-ge7b267444045c507654a2a3f758efee5d5b550df
Author: benjamin priour <priour.be@gmail.com>
Date: Fri Sep 1 00:01:29 2023 +0200
analyzer: Add support of placement new and improved operator new
[PR105948,PR94355]
Fixed spurious possibly-NULL warning always tagging along throwing
operator new despite it never returning NULL.
Now operator new is correctly recognized as possibly returning NULL
if and only if it is non-throwing or exceptions have been disabled.
Different standard signatures of operator new are now properly
recognized.
Added support of placement new, so that it is now properly recognized,
and a 'heap_allocated' region is no longer created for it.
Placement new size is also checked and a 'Wanalyzer-allocation-size'
is emitted when relevant, as well as always a 'Wanalyzer-out-of-bounds'.
'operator new' non-throwing variants are detected y checking the types
of the parameters.
Indeed, in a call to new (std::nothrow) () the chosen overload
has signature 'operator new (void*, std::nothrow_t&)', where the second
parameter is a reference. In a placement new, the second parameter will
always be a void pointer.
Prior to this patch, some buffers first allocated with 'new', then deleted
an thereafter used would result in a 'Wanalyzer-user-after-free'
warning. However the wording was "use after 'free'" instead of the
expected "use after 'delete'".
This patch fixes this by introducing a new kind of poisoned value,
namely POISON_KIND_DELETED.
Due to how the analyzer sees calls to non-throwing variants of
operator new, dereferencing a pointer freshly allocated in this fashion
caused both a 'Wanalyzer-use-of-uninitialized-value' and a
'Wanalyzer-null-dereference' to be emitted, while only the latter was
relevant. As a result, 'null-dereference' now supersedes
'use-of-uninitialized'.
Signed-off-by: benjamin priour <vultkayn@gcc.gnu.org>
gcc/analyzer/ChangeLog:
PR analyzer/105948
PR analyzer/94355
* analyzer.h (is_placement_new_p): New declaration.
* call-details.cc
(call_details::deref_ptr_arg): New function.
Dereference the argument at given index if possible.
* call-details.h: Declaration of the above function.
* kf-lang-cp.cc (is_placement_new_p): Returns true if the gcall
is recognized as a placement new.
(kf_operator_delete::impl_call_post): Unbinding a region and its
descendents now poisons with POISON_KIND_DELETED.
(register_known_functions_lang_cp): Known function "operator
delete" is now registered only once independently of its number of
arguments.
* region-model.cc (region_model::eval_condition): Now
recursively calls itself if any of the operand is wrapped in a
cast.
* sm-malloc.cc (malloc_state_machine::on_stmt):
Add placement new recognition.
* svalue.cc (poison_kind_to_str): Wording for the new PK.
* svalue.h (enum poison_kind): Add value POISON_KIND_DELETED.
gcc/testsuite/ChangeLog:
PR analyzer/105948
PR analyzer/94355
* g++.dg/analyzer/out-of-bounds-placement-new.C: Added a directive.
* g++.dg/analyzer/placement-new.C: Added tests.
* g++.dg/analyzer/new-2.C: New test.
* g++.dg/analyzer/noexcept-new.C: New test.
* g++.dg/analyzer/placement-new-size.C: New test.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes
2022-06-13 13:52 [Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes dmalcolm at gcc dot gnu.org
2023-06-30 14:39 ` [Bug analyzer/105948] " vultkayn at gcc dot gnu.org
2023-09-01 20:06 ` cvs-commit at gcc dot gnu.org
@ 2023-09-01 20:09 ` vultkayn at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: vultkayn at gcc dot gnu.org @ 2023-09-01 20:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105948
--- Comment #3 from Benjamin Priour <vultkayn at gcc dot gnu.org> ---
I believe the above patch resolves this PR.
I'm letting it sip in trunk for a few days before marking it as solved.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-01 20:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-13 13:52 [Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes dmalcolm at gcc dot gnu.org
2023-06-30 14:39 ` [Bug analyzer/105948] " vultkayn at gcc dot gnu.org
2023-09-01 20:06 ` cvs-commit at gcc dot gnu.org
2023-09-01 20:09 ` vultkayn 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).