public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
@ 2021-11-14 14:27 colomar.6.4.3 at gmail dot com
2021-11-14 14:30 ` [Bug c++/103233] " colomar.6.4.3 at gmail dot com
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2021-11-14 14:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
Bug ID: 103233
Summary: Warning from system libraries in user code: CWE-476
-Werror=analyzer-null-dereference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
There are two problems here:
One is a dereference of a NULL pointer in the standard C++ library code
(at least that's what -fanalyzer reports).
Another is that I'm seeing the error while compiling user code (my library):
<https://github.com/alejandro-colomar/libalx>
c++ -D _GNU_SOURCE -D _POSIX_C_SOURCE=200809L -D
SYSCONFDIR_='"/usr/local/etc/alx"' -O3 -Wall -Wextra -Winvalid-pch -fno-common
-Werror -fpic -isystem/usr/local/include -D_GNU_SOURCE
-D_POSIX_C_SOURCE=200809L -isystem/usr/include/opencv4
-isystem/usr/local/include -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L
-isystem/usr/local/include -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L -fanalyzer
-std=gnu++20 -Wno-vla -I /home/alx/src/alx/libalx/include -fpreprocessed -S
-o /home/alx/src/alx/libalx/tmp/alx/cv/features2d/orb.cxx.s
/home/alx/src/alx/libalx/tmp/alx/cv/features2d/orb.cxx.i
In member function 'void std::vector<_Tp,
_Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...)
[with _Args = {const cv::Point_<float>&}; _Tp = cv::Point_<float>; _Alloc =
std::allocator<cv::Point_<float> >]':
cc1plus: error: dereference of NULL '__cur' [CWE-476]
[-Werror=analyzer-null-dereference]
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': events 1-2
|
|/usr/include/c++/11/bits/vector.tcc:426:7:
| 426 | vector<_Tp, _Alloc>::
| | ^~~~~~~~~~~~~~~~~~~
| | |
| | (1) entry to 'std::vector<cv::Point_<float>
>::_M_realloc_insert<const cv::Point_<float>&>'
|......
| 436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) calling 'std::vector<cv::Point_<float>
>::_M_check_len' from 'std::vector<cv::Point_<float> >::_M_realloc_insert<const
cv::Point_<float>&>'
|
+--> 'std::vector<_Tp, _Alloc>::size_type std::vector<_Tp,
_Alloc>::_M_check_len(std::vector<_Tp, _Alloc>::size_type, const char*) const
[with _Tp = cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]':
events 3-5
|
|/usr/include/c++/11/bits/stl_vector.h:1756:7:
| 1756 | _M_check_len(size_type __n, const char* __s) const
| | ^~~~~~~~~~~~
| | |
| | (3) entry to 'std::vector<cv::Point_<float>
>::_M_check_len'
| 1757 | {
| 1758 | if (max_size() - size() < __n)
| | ~~
| | |
| | (4) following 'false' branch...
|......
| 1761 | const size_type __len = size() + (std::max)(size(),
__n);
| | ~~~~~~
| | |
| | (5)
...to here
|
<------+
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 6
|
|/usr/include/c++/11/bits/vector.tcc:436:21:
| 436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
| | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (6) returning to
'std::vector<cv::Point_<float> >::_M_realloc_insert<const cv::Point_<float>&>'
from 'std::vector<cv::Point_<float> >::_M_check_len'
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 7
|
|/usr/include/c++/11/bits/stl_vector.h:346:25:
| 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer();
| | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (7) following 'false' branch...
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 8
|
|/usr/include/c++/11/bits/vector.tcc:450:48:
| 450 | __new_start + __elems_before,
| | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~
| | |
| | (8) ...to here
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 9
|
|/usr/include/c++/11/bits/stl_uninitialized.h:1031:22:
| 1031 | for (; __first != __last; ++__first, (void)++__cur)
| | ~~~~~~~~^~~~~~~~~
| | |
| | (9) following 'true' branch (when '__first !=
<unknown>')...
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 10
|
|/usr/include/c++/11/bits/stl_construct.h:88:9:
| 88 | __location->~_Tp();
| | ^~~~~~~~~~
| | |
| | (10) ...to here
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 11
|
|cc1plus:
| (11): dereference of NULL '__cur'
|
cc1plus: error: dereference of possibly-NULL '__cur' [CWE-690]
[-Werror=analyzer-possible-null-dereference]
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': events 1-2
|
|/usr/include/c++/11/bits/vector.tcc:426:7:
| 426 | vector<_Tp, _Alloc>::
| | ^~~~~~~~~~~~~~~~~~~
| | |
| | (1) entry to 'std::vector<cv::Point_<float>
>::_M_realloc_insert<const cv::Point_<float>&>'
|......
| 436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) calling 'std::vector<cv::Point_<float>
>::_M_check_len' from 'std::vector<cv::Point_<float> >::_M_realloc_insert<const
cv::Point_<float>&>'
|
+--> 'std::vector<_Tp, _Alloc>::size_type std::vector<_Tp,
_Alloc>::_M_check_len(std::vector<_Tp, _Alloc>::size_type, const char*) const
[with _Tp = cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]':
events 3-5
|
|/usr/include/c++/11/bits/stl_vector.h:1756:7:
| 1756 | _M_check_len(size_type __n, const char* __s) const
| | ^~~~~~~~~~~~
| | |
| | (3) entry to 'std::vector<cv::Point_<float>
>::_M_check_len'
| 1757 | {
| 1758 | if (max_size() - size() < __n)
| | ~~
| | |
| | (4) following 'false' branch...
|......
| 1761 | const size_type __len = size() + (std::max)(size(),
__n);
| | ~~~~~~
| | |
| | (5)
...to here
|
<------+
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 6
|
|/usr/include/c++/11/bits/vector.tcc:436:21:
| 436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
| | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (6) returning to
'std::vector<cv::Point_<float> >::_M_realloc_insert<const cv::Point_<float>&>'
from 'std::vector<cv::Point_<float> >::_M_check_len'
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': events 7-8
|
|/usr/include/c++/11/bits/stl_vector.h:346:25:
| 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer();
| | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
| | | (8) ...to here
| | (7) following 'true' branch...
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 9
|
|/usr/include/c++/11/bits/allocator.h:201:47:
| 201 | return __allocator_base<_Tp>::allocate(__n, 0);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
| | |
| | (9) calling
'__gnu_cxx::new_allocator<cv::Point_<float> >::allocate' from
'std::vector<cv::Point_<float> >::_M_realloc_insert<const cv::Point_<float>&>'
|
+--> '_Tp*
__gnu_cxx::new_allocator<_Tp>::allocate(__gnu_cxx::new_allocator<_Tp>::size_type,
const void*) [with _Tp = cv::Point_<float>]': events 10-13
|
|/usr/include/c++/11/ext/new_allocator.h:103:7:
| 103 | allocate(size_type __n, const void* =
static_cast<const void*>(0))
| | ^~~~~~~~
| | |
| | (10) entry to
'__gnu_cxx::new_allocator<cv::Point_<float> >::allocate'
|......
| 111 | if (__builtin_expect(__n > this->_M_max_size(),
false))
| | ~~
| | |
| | (11) following 'false' branch...
|......
| 127 | return static_cast<_Tp*>(::operator new(__n *
sizeof(_Tp)));
| |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (12) ...to
here
| | (13) this
call could return NULL
|
<------+
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 14
|
|/usr/include/c++/11/bits/allocator.h:201:47:
| 201 | return __allocator_base<_Tp>::allocate(__n, 0);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
| | |
| | (14) returning to
'std::vector<cv::Point_<float> >::_M_realloc_insert<const cv::Point_<float>&>'
from '__gnu_cxx::new_allocator<cv::Point_<float> >::allocate'
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 15
|
|/usr/include/c++/11/bits/stl_uninitialized.h:1031:22:
| 1031 | for (; __first != __last; ++__first, (void)++__cur)
| | ~~~~~~~~^~~~~~~~~
| | |
| | (15) following 'true' branch (when '__first
!= <unknown>')...
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 16
|
|/usr/include/c++/11/bits/stl_construct.h:88:9:
| 88 | __location->~_Tp();
| | ^~~~~~~~~~
| | |
| | (16) ...to here
|
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_<float>&}; _Tp =
cv::Point_<float>; _Alloc = std::allocator<cv::Point_<float> >]': event 17
|
|cc1plus:
| (17): '__cur' could be NULL: unchecked value from (13)
|
cc1plus: all warnings being treated as errors
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
@ 2021-11-14 14:30 ` colomar.6.4.3 at gmail dot com
2021-11-14 14:57 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2021-11-14 14:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #1 from Alejandro Colomar <colomar.6.4.3 at gmail dot com> ---
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ dpkg -l "*[cg]++*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=========================-============-============-===============================================
un c++-compiler <none> <none> (no description
available)
un c++abi2-dev <none> <none> (no description
available)
ii g++ 4:11.2.0-2 amd64 GNU C++ compiler
ii g++-11 11.2.0-10 amd64 GNU C++ compiler
un g++-11-multilib <none> <none> (no description
available)
un g++-multilib <none> <none> (no description
available)
un g++-x86-64-linux-gnu <none> <none> (no description
available)
ii lib32stdc++6 11.2.0-10 amd64 GNU Standard C++
Library v3 (32 bit Version)
un libg++2.8-dev <none> <none> (no description
available)
un libg++27-dev <none> <none> (no description
available)
un libg++272-dev <none> <none> (no description
available)
un libsigc++-2.0-0c2a <none> <none> (no description
available)
ii libsigc++-2.0-0v5:amd64 2.10.4-2 amd64 type-safe Signal
Framework for C++ - runtime
ii libstdc++-10-dev:amd64 10.3.0-12 amd64 GNU Standard C++
Library v3 (development files)
un libstdc++-10-doc <none> <none> (no description
available)
ii libstdc++-11-dev:amd64 11.2.0-10 amd64 GNU Standard C++
Library v3 (development files)
un libstdc++-11-doc <none> <none> (no description
available)
un libstdc++-dev <none> <none> (no description
available)
un libstdc++2.10-dev <none> <none> (no description
available)
un libstdc++2.8-dev <none> <none> (no description
available)
un libstdc++2.9-dev <none> <none> (no description
available)
un libstdc++2.9-glibc2.1-dev <none> <none> (no description
available)
un libstdc++3.0-dev <none> <none> (no description
available)
ii libstdc++6:amd64 11.2.0-10 amd64 GNU Standard C++
Library v3
un libstdc++6-11-dbg <none> <none> (no description
available)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
2021-11-14 14:30 ` [Bug c++/103233] " colomar.6.4.3 at gmail dot com
@ 2021-11-14 14:57 ` redi at gcc dot gnu.org
2021-11-14 15:32 ` [Bug analyzer/103233] " alx.manpages at gmail dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2021-11-14 14:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2021-11-14
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Alejandro Colomar from comment #0)
> There are two problems here:
>
> One is a dereference of a NULL pointer in the standard C++ library code
> (at least that's what -fanalyzer reports).
The analyzer doesn't support C++ properly yet, and is completely wrong here.
See below.
> Another is that I'm seeing the error while compiling user code (my library):
> <https://github.com/alejandro-colomar/libalx>
What error? Please provide the code to reproduce the problem, not just a URL,
see https://gcc.gnu.org/bugs
> |/usr/include/c++/11/bits/stl_vector.h:346:25:
> | 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) :
> pointer();
> | |
> ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | | |
> | | (7) following 'false' branch...
This cannot happen. The length is this->size() + 1 and we already checked for
overflow, so it is guaranteed to be a positive integer.
> |......
> | 127 | return static_cast<_Tp*>(::operator new(__n *
> sizeof(_Tp)));
> | |
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | | |
> | | (12)
> ...to here
> | | (13) this
> call could return NULL
This is nonsense, operator new(size_t) cannot return null.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
2021-11-14 14:30 ` [Bug c++/103233] " colomar.6.4.3 at gmail dot com
2021-11-14 14:57 ` redi at gcc dot gnu.org
@ 2021-11-14 15:32 ` alx.manpages at gmail dot com
2021-11-15 23:27 ` dmalcolm at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: alx.manpages at gmail dot com @ 2021-11-14 15:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #3 from alx.manpages at gmail dot com ---
Hi Jonathan,
On 11/14/21 15:57, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
>
> Jonathan Wakely <redi at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED |WAITING
> Last reconfirmed| |2021-11-14
> Ever confirmed|0 |1
>
> --- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to Alejandro Colomar from comment #0)
>> There are two problems here:
>>
>> One is a dereference of a NULL pointer in the standard C++ library code
>> (at least that's what -fanalyzer reports).
>
> The analyzer doesn't support C++ properly yet, and is completely wrong here.
> See below.
>
>
>
>> Another is that I'm seeing the error while compiling user code (my library):
>> <https://github.com/alejandro-colomar/libalx>
>
> What error? Please provide the code to reproduce the problem, not just a URL,
> see https://gcc.gnu.org/bugs
Well, not an error, but a warning (I transformed it into an error with
-Werror).
The error/warning that I referred to
was the one I copied entirely
(including the command to produce it).
The case that I reported was compiling an already preprocessed file.
Since it was a big temporary file
(and probably less readable than the source), I didn't share it.
I simplified the file, and compiled it directly,
to simplify reproducing it:
$ cat sys_warning.cxx
/******************************************************************************
* Copyright (c) 2018 by Alejandro Colomar <alx.manpages@gmail.com>
* SPDX-License-Identifier: GPL-2.0-only
******************************************************************************/
#include <stddef.h>
#include <vector>
#include <opencv2/calib3d.hpp>
#include <opencv2/core/base.hpp>
#include <opencv2/core/mat.hpp>
#include <opencv2/features2d.hpp>
#include <opencv2/imgproc.hpp>
static constexpr int MAX_FEATURES = 50000;
static constexpr double GOOD_MATCH_P = 0.25;
[[gnu::nonnull(1, 2)]]
void orb_align(const class cv::Mat *ref,
class cv::Mat *img,
class cv::Mat *img_matches);
void orb_align(const class cv::Mat *ref,
class cv::Mat *img,
class cv::Mat *img_matches)
{
class std::vector <class cv::KeyPoint> keypoints_0;
class std::vector <class cv::KeyPoint> keypoints_1;
class cv::Mat descriptors_0;
class cv::Mat descriptors_1;
struct cv::Ptr <class cv::Feature2D> orb;
class std::vector <class cv::DMatch> matches;
struct cv::Ptr <class cv::DescriptorMatcher> matcher;
ptrdiff_t good_matches;
class std::vector <class cv::Point_ <float>> points_0;
class std::vector <class cv::Point_ <float>> points_1;
ptrdiff_t size;
class cv::Mat img_hg;
class cv::Mat img_align;
/* Detect ORB features & compute descriptors */
orb = cv::ORB::create(MAX_FEATURES, 1.2f, 8, 31, 0, 2,
cv::ORB::HARRIS_SCORE, 31, 20);
orb->detectAndCompute(*ref, cv::Mat(), keypoints_0, descriptors_0,
false);
orb->detectAndCompute(*img, cv::Mat(), keypoints_1, descriptors_1,
false);
/* Match structures */
matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");
matcher->match(descriptors_1, descriptors_0, matches, cv::Mat());
/* Sort matches by score */
std::sort(matches.begin(), matches.end());
/* Remove not so good matches */
good_matches = GOOD_MATCH_P * matches.size();
matches.erase(matches.begin() + good_matches, matches.end());
/* Draw top matches */
if (img_matches)
cv::drawMatches(*img, keypoints_1, *ref, keypoints_0, matches,
*img_matches, cv::Scalar::all(-1),
cv::Scalar::all(-1), std::vector<char>(),
cv::DrawMatchesFlags::DEFAULT);
/* Extract location of good matches */
size = matches.size();
for (ptrdiff_t i = 0; i < size; i++) {
points_1.push_back(keypoints_1[matches[i].queryIdx].pt);
points_0.push_back(keypoints_0[matches[i].trainIdx].pt);
}
/* Find homography */
img_hg = cv::findHomography(points_1, points_0, cv::RANSAC,
3, cv::noArray(), 2000, 0.995);
/* Use homography to warp image */
cv::warpPerspective(*img, img_align, img_hg, ref->size(),
cv::INTER_LINEAR, cv::BORDER_CONSTANT,
cv::Scalar());
/* Write img_align into img */
*img = img_align;
img_align.release();
}
$ c++ -D _GNU_SOURCE -D _POSIX_C_SOURCE=200809L -O3 -Wall -Wextra
-Winvalid-pch -fno-common -fpic -isystem/usr/include/opencv4 -fanalyzer
-std=gnu++20 -Wno-vla -S sys_warning.cxx
You'll need libopencv-dev (or equivalent) to compile.
>
>
>> |/usr/include/c++/11/bits/stl_vector.h:346:25:
>> | 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) :
>> pointer();
>> | |
>> ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | | |
>> | | (7) following 'false' branch...
>
> This cannot happen. The length is this->size() + 1 and we already checked for
> overflow, so it is guaranteed to be a positive integer.
>
>
>> |......
>> | 127 | return static_cast<_Tp*>(::operator new(__n *
>> sizeof(_Tp)));
>> | |
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | | |
>> | | (12)
>> ...to here
>> | | (13) this
>> call could return NULL
>
>
> This is nonsense, operator new(size_t) cannot return null.
Okay, then I hope this helps improving fanalyzer :)
Regards,
Alex
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (2 preceding siblings ...)
2021-11-14 15:32 ` [Bug analyzer/103233] " alx.manpages at gmail dot com
@ 2021-11-15 23:27 ` dmalcolm at gcc dot gnu.org
2021-11-15 23:42 ` colomar.6.4.3 at gmail dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-11-15 23:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The analyzer doesn't properly support C++ yet; in particular, it doesn't yet
"understand" exception handling.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (3 preceding siblings ...)
2021-11-15 23:27 ` dmalcolm at gcc dot gnu.org
@ 2021-11-15 23:42 ` colomar.6.4.3 at gmail dot com
2021-11-15 23:48 ` colomar.6.4.3 at gmail dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2021-11-15 23:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #5 from Alejandro Colomar <colomar.6.4.3 at gmail dot com> ---
Is `-fanalyzer` allowed to report errors from system headers exclusively?
I mean,
ignoring the fact that C++ is unsupported,
there's no report at all that relates that error report to my code;
not even to libopencv's code.
If glibc had a bug,
and I compiled a C program that had perfectly defined behavior,
would I receive a report for that error?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (4 preceding siblings ...)
2021-11-15 23:42 ` colomar.6.4.3 at gmail dot com
@ 2021-11-15 23:48 ` colomar.6.4.3 at gmail dot com
2021-11-15 23:52 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2021-11-15 23:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #6 from Alejandro Colomar <colomar.6.4.3 at gmail dot com> ---
I mean, I'm not against that,
in fact I think it's good to know if my program is going to crash,
even if it's not my fault,
but then I wonder if cases such as
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746>
should also report a warning in user code,
even with more reason (in that other case it is the user's fault).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (5 preceding siblings ...)
2021-11-15 23:48 ` colomar.6.4.3 at gmail dot com
@ 2021-11-15 23:52 ` pinskia at gcc dot gnu.org
2021-11-16 11:32 ` alx.manpages at gmail dot com
2021-12-13 15:45 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-15 23:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Alejandro Colomar from comment #5)
> If glibc had a bug,
> and I compiled a C program that had perfectly defined behavior,
> would I receive a report for that error?
Most C headers don't contain that much code in them unlike C++ headers which
contains a lot of the code due to template and such.
That being said if there was a C system header that had an issue and analyzer
was used and it would definitely report the failure.
But that ignores the issue that C system headers are mostly just function
declarations and does not include much function definitions at all.
So again this is not just C vs C++ but rather how much code is in C++ system
headers and C++ not being supported.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (6 preceding siblings ...)
2021-11-15 23:52 ` pinskia at gcc dot gnu.org
@ 2021-11-16 11:32 ` alx.manpages at gmail dot com
2021-12-13 15:45 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: alx.manpages at gmail dot com @ 2021-11-16 11:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
--- Comment #8 from alx.manpages at gmail dot com ---
Hi Andrew,
On 11/16/21 00:52, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
>
> --- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Alejandro Colomar from comment #5)
>> If glibc had a bug,
>> and I compiled a C program that had perfectly defined behavior,
>> would I receive a report for that error?
>
> Most C headers don't contain that much code in them unlike C++ headers which
> contains a lot of the code due to template and such.
> That being said if there was a C system header that had an issue and analyzer
> was used and it would definitely report the failure.
>
> But that ignores the issue that C system headers are mostly just function
> declarations and does not include much function definitions at all.
> So again this is not just C vs C++ but rather how much code is in C++ system
> headers and C++ not being supported.
Seems fair enough to me.
Feel free to close the bug.
Thanks,
Alex
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
` (7 preceding siblings ...)
2021-11-16 11:32 ` alx.manpages at gmail dot com
@ 2021-12-13 15:45 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-13 15:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |WONTFIX
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Closing as WONTFIX, even though it will get fixed eventually, once C++ is
supported.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-13 15:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-14 14:27 [Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference colomar.6.4.3 at gmail dot com
2021-11-14 14:30 ` [Bug c++/103233] " colomar.6.4.3 at gmail dot com
2021-11-14 14:57 ` redi at gcc dot gnu.org
2021-11-14 15:32 ` [Bug analyzer/103233] " alx.manpages at gmail dot com
2021-11-15 23:27 ` dmalcolm at gcc dot gnu.org
2021-11-15 23:42 ` colomar.6.4.3 at gmail dot com
2021-11-15 23:48 ` colomar.6.4.3 at gmail dot com
2021-11-15 23:52 ` pinskia at gcc dot gnu.org
2021-11-16 11:32 ` alx.manpages at gmail dot com
2021-12-13 15:45 ` 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).