Michael Jones [2019-11-20 18:12:14]:
> You may need #include_next, to avoid recursion.
Is this some theoretical experience? Or you can provide me with some build
breakage? Just wondering, because #include should work this out with "" and
<>.
BTW I would rather rename that include file to
You may need #include_next, to avoid recursion.
On Wed, Nov 20, 2019, 15:45 Petr Štetiar wrote:
> In order to allow seamless assert() usage in release builds without the
> need for fiddling with CMake C flags as CMake adds -DNDEBUG switch in
> release builds which disable assert().
>
>
clang-10 analyzer reports following:
avl.c:671:25: warning: Access to field 'parent' results in a dereference of a
null pointer (loaded from field 'right')
node->right->parent = parent;
~ ^
Which seems to be impossible to trigger via exported AVL public API, but
it
clang-10 analyzer reports following:
blobmsg_json.c:285:2: warning: The expression is an uninitialized value. The
computed value will also be garbage
s->indent_level++;
^
Signed-off-by: Petr Štetiar
---
blobmsg_json.c | 4 ++--
1 file changed, 2
Fixes following leaks of memory:
352 (72 direct, 280 indirect) bytes in 1 blocks are definitely lost in loss
record 3 of 3
at 0x4C31B25: calloc
by 0x5042E1F: json_object_new_array
by 0x5044B02: json_tokener_parse_ex
by 0x5045316: json_tokener_parse_verbose
by 0x504537D:
In order to allow seamless assert() usage in release builds without the
need for fiddling with CMake C flags as CMake adds -DNDEBUG switch in
release builds which disable assert().
Signed-off-by: Petr Štetiar
---
assert.h | 9 +
1 file changed, 9 insertions(+)
create mode 100644
Fixes following leak of memory:
6,016 bytes in 1 blocks are possibly lost in loss record 1 of 1
at 0x4C31B25: calloc
by 0x1098F8: main (jshn.c:353)
Signed-off-by: Petr Štetiar
---
jshn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/jshn.c b/jshn.c
index
clang-10 analyzer reports following:
base64.c:325:20: warning: Array access (from variable 'target') results in a
null pointer dereference
target[tarindex] = 0;
~~ ^
and prepared test case confirms it:
Invalid write of size 1
at 0x4E4463F:
gcc-9 on x86/64 has reported following issues:
base64.c:173:17: error: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
base64.c:230:18: error: comparison of integer expressions of different
signedness: ‘int’ and
Uses currently proof-of-concept openwrt-ci[1] in order to:
* improve the quality of the codebase in various areas
* decrease code review time and help merging contributions faster
* get automagic feedback loop on various platforms and tools
- out of tree build with OpenWrt SDK on following
For improved QA etc. for the start with initial test cases for avl,
base64 and jshn.
Signed-off-by: Petr Štetiar
---
CMakeLists.txt| 5 +++
tests/CMakeLists.txt | 10 +
tests/cram/CMakeLists.txt | 27
tests/cram/test_avl.t | 10 +
Let's enforce additional automatic checks enforced by the compiler in
order to catch possible errors during compilation.
Signed-off-by: Petr Štetiar
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index
Hi,
I've made libubox compile with -Wextra flags, tried to make clang/cppcheck
static code analyzers happy, fixed some memleaks, added initial cram based
unit tests for avl/base64/jshn components and added GitLab CI support.
Changes in v2:
- make avl, base64 crash with invalid inputs (yousong)
Yousong Zhou [2019-11-20 22:01:22]:
> By the way, will assert(node-parent != NULL) suffice to inform the
> analyzer the underlying details? If it does, we could also apply it
> to b64_encode(), b64_decode().
BTW in libnl-tiny I've learned, that using assert() in CMake release builds
needs
When for example a /60 is assigned to a network the last 4 bits of the
ip6hint are unused. Emit a warning if any of these unused bits is set as
it indicates that someone didn't understand how the hint is used. (As I
did earlier today resulting in spending some time understanding the
code.)
---
Currently the patch only changes break to use goto statement instead.
But not necessary acutually since the ret value checked after the for loop.
So it is okay for the break case before changed by the patch also.
Signed-off-by: Tokunori Ikegami
Cc: openwrt-devel@lists.openwrt.org
---
Yousong Zhou [2019-11-20 22:03:06]:
> On Wed, 20 Nov 2019 at 20:01, Petr Štetiar wrote:
> >
> > clang-10 analyzer reports following:
> >
> > blobmsg_json.c:285:2: warning: The expression is an uninitialized value.
> > The computed value will also be garbage
> > s->indent_level++;
> >
On Wed, 20 Nov 2019 at 20:01, Petr Štetiar wrote:
>
> clang-10 analyzer reports following:
>
> blobmsg_json.c:285:2: warning: The expression is an uninitialized value. The
> computed value will also be garbage
> s->indent_level++;
> ^
Add else branch to
On Wed, 20 Nov 2019 at 21:46, Yousong Zhou wrote:
>
> On Wed, 20 Nov 2019 at 21:33, Petr Štetiar wrote:
> >
> > Yousong Zhou [2019-11-20 20:33:06]:
> >
> > Hi,
> >
> > thanks for review!
> >
> > > The first check (node->left == NULL && node->right == NULL) if
> > > matched, will return.
> >
> >
On Wed, 20 Nov 2019 at 21:33, Petr Štetiar wrote:
>
> Yousong Zhou [2019-11-20 20:33:06]:
>
> Hi,
>
> thanks for review!
>
> > The first check (node->left == NULL && node->right == NULL) if
> > matched, will return.
>
> You can see the code path leading to null pointer dereference for
Jonas Gorski [2019-11-20 14:29:50]:
Hi,
> Does it still compile when only applying this patch? If not, you need
> to move it to after fixing all issues it now warns about (and I guess
> errors), to keep bisectability.
good point, thanks. I've reordered the commits.
-- ynezz
Yousong Zhou [2019-11-20 20:33:06]:
Hi,
thanks for review!
> The first check (node->left == NULL && node->right == NULL) if
> matched, will return.
You can see the code path leading to null pointer dereference for yourself[1].
I wish, that analyzer could output test case directly :-) I wanted
On Wed, 20 Nov 2019 at 13:00, Petr Štetiar wrote:
>
> Let's enforce additional automatic checks enforced by the compiler in
> order to catch possible errors during compilation.
Does it still compile when only applying this patch? If not, you need
to move it to after fixing all issues it now
On Wed, 20 Nov 2019 at 20:01, Petr Štetiar wrote:
>
> clang-10 analyzer reports following:
>
> avl.c:671:25: warning: Access to field 'parent' results in a dereference of
> a null pointer (loaded from field 'right')
> node->right->parent = parent;
>~ ^
>
> Which
clang-10 analyzer reports following:
blobmsg_json.c:285:2: warning: The expression is an uninitialized value. The
computed value will also be garbage
s->indent_level++;
^
Signed-off-by: Petr Štetiar
---
blobmsg_json.c | 4 ++--
1 file changed, 2
clang-10 analyzer reports following:
avl.c:671:25: warning: Access to field 'parent' results in a dereference of a
null pointer (loaded from field 'right')
node->right->parent = parent;
~ ^
Which seems to be impossible to trigger via exported AVL public API, but
it
clang-10 analyzer reports following:
base64.c:325:20: warning: Array access (from variable 'target') results in a
null pointer dereference
target[tarindex] = 0;
~~ ^
and prepared test case confirms it:
Invalid write of size 1
at 0x4E4463F:
Fixes following leaks of memory:
352 (72 direct, 280 indirect) bytes in 1 blocks are definitely lost in loss
record 3 of 3
at 0x4C31B25: calloc
by 0x5042E1F: json_object_new_array
by 0x5044B02: json_tokener_parse_ex
by 0x5045316: json_tokener_parse_verbose
by 0x504537D:
Fixes following leak of memory:
6,016 bytes in 1 blocks are possibly lost in loss record 1 of 1
at 0x4C31B25: calloc
by 0x1098F8: main (jshn.c:353)
Signed-off-by: Petr Štetiar
---
jshn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/jshn.c b/jshn.c
index
gcc-9 on x86/64 has reported following issues:
base64.c:173:17: error: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
base64.c:230:18: error: comparison of integer expressions of different
signedness: ‘int’ and
Hi,
I've made libubox compile with -Wextra flags, tried to make clang/cppcheck
static code analyzers happy, fixed some memleaks, added initial cram based
unit tests for avl/base64/jshn components and added GitLab CI support[1].
1.
Uses currently proof-of-concept openwrt-ci[1] in order to:
* improve the quality of the codebase in various areas
* decrease code review time and help merging contributions faster
* get automagic feedback loop on various platforms and tools
- out of tree build with OpenWrt SDK on following
Let's enforce additional automatic checks enforced by the compiler in
order to catch possible errors during compilation.
Signed-off-by: Petr Štetiar
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index
For improved QA etc. for the start with initial test cases for avl,
base64 and jshn.
Signed-off-by: Petr Štetiar
---
CMakeLists.txt| 5 +++
tests/CMakeLists.txt | 10 +
tests/cram/CMakeLists.txt | 27
tests/cram/test_avl.t | 10 +
34 matches
Mail list logo
