[PATCH v2] libubox: fix BLOBMSG_CAST_INT64 (do not override BLOBMSG_TYPE_DOUBLE)
Commit 9e52171 ('blobmsg: introduce BLOBMSG_CAST_INT64') broke
blobmsg_parse() for BLOBMSG_TYPE_DOUBLE.
This is because the enum definition leads to the following double
define for BLOBMSG_CAST_INT64/BLOBMSG_TYPE_DOUBLE as value 8.
Tested with:
$ cat test-enum-001.c
#include
enum blobmsg_type {
BLOBMSG_TYPE_UNSPEC,
BLOBMSG_TYPE_ARRAY,
BLOBMSG_TYPE_TABLE,
BLOBMSG_TYPE_STRING,
BLOBMSG_TYPE_INT64,
BLOBMSG_TYPE_INT32,
BLOBMSG_TYPE_INT16,
BLOBMSG_TYPE_INT8,
BLOBMSG_TYPE_DOUBLE,
__BLOBMSG_TYPE_LAST,
BLOBMSG_TYPE_LAST = __BLOBMSG_TYPE_LAST - 1,
BLOBMSG_TYPE_BOOL = BLOBMSG_TYPE_INT8,
BLOBMSG_CAST_INT64,
};
int main(int artc, char* argv[]) {
printf("BLOBMSG_TYPE_UNSPEC: %d\n", BLOBMSG_TYPE_UNSPEC);
printf("BLOBMSG_TYPE_ARRAY: %d\n", BLOBMSG_TYPE_ARRAY);
printf("BLOBMSG_TYPE_TABLE: %d\n", BLOBMSG_TYPE_TABLE);
printf("BLOBMSG_TYPE_STRING: %d\n", BLOBMSG_TYPE_STRING);
printf("BLOBMSG_TYPE_INT64: %d\n", BLOBMSG_TYPE_INT64);
printf("BLOBMSG_TYPE_INT32: %d\n", BLOBMSG_TYPE_INT32);
printf("BLOBMSG_TYPE_INT16: %d\n", BLOBMSG_TYPE_INT16);
printf("BLOBMSG_TYPE_INT8: %d\n", BLOBMSG_TYPE_INT8);
printf("BLOBMSG_TYPE_DOUBLE: %d\n", BLOBMSG_TYPE_DOUBLE);
printf("__BLOBMSG_TYPE_LAST: %d\n", __BLOBMSG_TYPE_LAST);
printf("BLOBMSG_TYPE_LAST: %d\n", BLOBMSG_TYPE_LAST);
printf("BLOBMSG_TYPE_BOOL: %d\n", BLOBMSG_TYPE_BOOL);
printf("BLOBMSG_CAST_INT64: %d\n", BLOBMSG_CAST_INT64);
return 0;
}
$ gcc test-enum-001.c
$ ./a.out
BLOBMSG_TYPE_UNSPEC: 0
BLOBMSG_TYPE_ARRAY: 1
BLOBMSG_TYPE_TABLE: 2
BLOBMSG_TYPE_STRING: 3
BLOBMSG_TYPE_INT64: 4
BLOBMSG_TYPE_INT32: 5
BLOBMSG_TYPE_INT16: 6
BLOBMSG_TYPE_INT8: 7
BLOBMSG_TYPE_DOUBLE: 8
__BLOBMSG_TYPE_LAST: 9
BLOBMSG_TYPE_LAST: 8
BLOBMSG_TYPE_BOOL: 7
BLOBMSG_CAST_INT64: 8
Fix this by changing the enum defintion to assign BLOBMSG_CAST_INT64 to
the unique value 9.
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- re-send after subscribing to the mailing list
- change patch subject prefix from blobmsg to libubox
---
blobmsg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/blobmsg.h b/blobmsg.h
index 4a151c7..1f0634d 100644
--- a/blobmsg.h
+++ b/blobmsg.h
@@ -31,11 +31,11 @@ enum blobmsg_type {
BLOBMSG_TYPE_INT32,
BLOBMSG_TYPE_INT16,
BLOBMSG_TYPE_INT8,
+ BLOBMSG_TYPE_BOOL = BLOBMSG_TYPE_INT8,
BLOBMSG_TYPE_DOUBLE,
__BLOBMSG_TYPE_LAST,
BLOBMSG_TYPE_LAST = __BLOBMSG_TYPE_LAST - 1,
- BLOBMSG_TYPE_BOOL = BLOBMSG_TYPE_INT8,
- BLOBMSG_CAST_INT64,
+ BLOBMSG_CAST_INT64 = __BLOBMSG_TYPE_LAST,
};
struct blobmsg_hdr {
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v1 2/2] libubox: tests: add more blobmsg/json test cases
* add mixed int/double tests
* add blobmsg_cast_u64/blobmsg_cast_s64 tests
Signed-off-by: Peter Seiderer
---
tests/cram/test_blobmsg_types.t | 82 +++
tests/test-blobmsg-types.c | 371
2 files changed, 453 insertions(+)
create mode 100644 tests/cram/test_blobmsg_types.t
create mode 100644 tests/test-blobmsg-types.c
diff --git a/tests/cram/test_blobmsg_types.t b/tests/cram/test_blobmsg_types.t
new file mode 100644
index 000..190e1f2
--- /dev/null
+++ b/tests/cram/test_blobmsg_types.t
@@ -0,0 +1,82 @@
+check that blobmsg is producing expected results:
+
+ $ [ -n "$TEST_BIN_DIR" ] && export PATH="$TEST_BIN_DIR:$PATH"
+
+ $ valgrind --quiet --leak-check=full test-blobmsg-types
+ [*] blobmsg dump:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: -9223372036854775808
+ int32_max: 2147483647
+ int32_min: -2147483648
+ int16_max: 32767
+ int16_min: -32768
+ int8_max: 127
+ int8_min: -128
+ double_max: 1.797693e+308
+ double_min: 2.225074e-308
+ [*] blobmsg dump cast_u64:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: 9223372036854775808
+ int32_max: 2147483647
+ int32_min: 2147483648
+ int16_max: 32767
+ int16_min: 32768
+ int8_max: 127
+ int8_min: 128
+ double_max: 1.797693e+308
+ double_min: 2.225074e-308
+ [*] blobmsg dump cast_s64:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: -9223372036854775808
+ int32_max: 2147483647
+ int32_min: -2147483648
+ int16_max: 32767
+ int16_min: -32768
+ int8_max: 127
+ int8_min: -128
+ double_max: 1.797693e+308
+ double_min: 2.225074e-308
+
+ [*] blobmsg to json: {"string":"Hello,
world!","int64_max":9223372036854775807,"int64_min":-9223372036854775808,"int32_max":2147483647,"int32_min":-2147483648,"int16_max":32767,"int16_min":-32768,"int8_max":true,"int8_min":true,"double_max":179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00,"double_min":0.00}
+
+ [*] blobmsg from json:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: -9223372036854775808
+ int32_max: 2147483647
+ int32_min: -2147483648
+ int16_max: 32767
+ int16_min: -32768
+ int8_max: 1
+ int8_min: 1
+ double_max: 1.797693e+308
+ double_min: 0.00e+00
+
+ [*] blobmsg from json/cast_u64:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: 9223372036854775808
+ int32_max: 2147483647
+ int32_min: 2147483648
+ int16_max: 32767
+ int16_min: 4294934528
+ int8_max: 1
+ int8_min: 1
+ double_max: 1.797693e+308
+ double_min: 0.00e+00
+
+ [*] blobmsg from json/cast_s64:
+ string: Hello, world!
+ int64_max: 9223372036854775807
+ int64_min: -9223372036854775808
+ int32_max: 2147483647
+ int32_min: -2147483648
+ int16_max: 32767
+ int16_min: -32768
+ int8_max: 1
+ int8_min: 1
+ double_max: 1.797693e+308
+ double_min: 0.00e+00
diff --git a/tests/test-blobmsg-types.c b/tests/test-blobmsg-types.c
new file mode 100644
index 000..4d77a27
--- /dev/null
+++ b/tests/test-blobmsg-types.c
@@ -0,0 +1,371 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "blobmsg.h"
+#include "blobmsg_json.h"
+
+enum {
+ FOO_STRING,
+ FOO_INT64_MAX,
+ FOO_INT64_MIN,
+ FOO_INT32_MAX,
+ FOO_INT32_MIN,
+ FOO_INT16_MAX,
+ FOO_INT16_MIN,
+ FOO_INT8_MAX,
+ FOO_INT8_MIN,
+ FOO_DOUBLE_MAX,
+ FOO_DOUBLE_MIN,
+ __FOO_MAX
+};
+
+static const struct blobmsg_policy pol[] = {
+ [FOO_STRING] = {
+ .name = "string",
+ .type = BLOBMSG_TYPE_STRING,
+ },
+ [FOO_INT64_MAX] = {
+ .name = "int64_max",
+ .type = BLOBMSG_TYPE_INT64,
+ },
+ [FOO_INT64_MIN] = {
+ .name = "int64_min",
+ .type = BLOBMSG_TYPE_INT64,
+ },
+ [FOO_INT32_MAX] = {
+ .name = "int32_max",
+ .type = BLOBMSG_TYPE_INT32,
+ },
+ [FOO_INT32_MIN] = {
+ .name = "int32_min",
+ .type = BLOBMSG_TYPE_INT32,
+ },
+ [FOO_INT16_MAX] = {
+ .name = "int16_max",
+ .type = BLOBMSG_TYPE_INT16,
+ },
+ [FOO_INT16_MIN] = {
+ .name = "int16_min",
+ .type = BLOBMSG_TYPE_INT16,
+ },
+ [FOO_INT8_MAX] = {
+ .name = "int8_max",
+ .type = BLOBMSG_T
[PATCH v1 1/2] libubox: fix test_base64.t for bash
On my system 'make test' fails like the following: $ make test Running tests... Test project .../build_libubox Start 1: cram 1/2 Test #1: cram .***Failed 38.05 sec Start 2: shunit2 2/2 Test #2: shunit2 .. Passed0.21 sec 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 38.27 sec The following tests FAILED: 1 - cram (Failed) Errors while running CTest make: *** [Makefile:105: test] Error 8 $ cat Testing/Temporary/LastTest.log Start testing: Mar 06 11:36 CET -- 1/2 Testing: cram 1/2 Test: cram Command: ".../tests/cram/.venv/bin/cram" ".../tests/cram/test_avl.t" ".../tests/cram/test_base64.t" ".../tests/cram/test_blob_parse.t" ".../tests/cram/test_blobmsg.t" ".../tests/cram/test_blobmsg_check_array.t" ".../tests/cram/test_blobmsg_parse.t" ".../tests/cram/test_blobmsg_procd_instance.t" ".../tests/cram/test_jshn.t" ".../tests/cram/test_json_script.t" ".../tests/cram/test_list.t" ".../tests/cram/test_runqueue.t" Directory: .../tests/cram "cram" start time: Mar 06 11:36 CET Output: -- .! --- .../tests/cram/test_base64.t +++ .../tests/cram/test_base64.t.err @@ -41,13 +41,17 @@ $ alias check="grep Assertion output.log | sed 's;.*\(b64_.*code\).*\(Assertion.*$\);\1: \2;' | LC_ALL=C sort" $ test-b64_decode > output.log 2>&1; check + /bin/sh: line 10: 2441 Aborted (core dumped) test-b64_decode > output.log 2>&1 b64_decode: Assertion `dest && targsize > 0' failed. $ test-b64_encode > output.log 2>&1; check + /bin/sh: line 12: 2456 Aborted (core dumped) test-b64_encode > output.log 2>&1 b64_encode: Assertion `dest && targsize > 0' failed. $ test-b64_decode-san > output.log 2>&1; check + /bin/sh: line 14: 2473 Aborted (core dumped) test-b64_decode-san > output.log 2>&1 b64_decode: Assertion `dest && targsize > 0' failed. $ test-b64_encode-san > output.log 2>&1; check + /bin/sh: line 16: 2487 Aborted (core dumped) test-b64_encode-san > output.log 2>&1 b64_encode: Assertion `dest && targsize > 0' failed. . # Ran 11 tests, 0 skipped, 1 failed. Test time = 38.22 sec -- Test Failed. "cram" end time: Mar 06 11:37 CET "cram" time elapsed: 00:00:38 -- [...] My shell/bash seems to emit a more detailed failure message than expected. Fix this by complete avoiding the failure message using command substitution instead of direct command execution. Signed-off-by: Peter Seiderer --- tests/cram/test_base64.t | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/cram/test_base64.t b/tests/cram/test_base64.t index b028ac8..33fb454 100644 --- a/tests/cram/test_base64.t +++ b/tests/cram/test_base64.t @@ -40,14 +40,14 @@ check that b64_encode and b64_decode assert invalid input $ alias check="grep Assertion output.log | sed 's;.*\(b64_.*code\).*\(Assertion.*$\);\1: \2;' | LC_ALL=C sort" - $ test-b64_decode > output.log 2>&1; check + $ $(test-b64_decode > output.log 2>&1); check b64_decode: Assertion `dest && targsize > 0' failed. - $ test-b64_encode > output.log 2>&1; check + $ $(test-b64_encode > output.log 2>&1); check b64_encode: Assertion `dest && targsize > 0' failed. - $ test-b64_decode-san > output.log 2>&1; check + $ $(test-b64_decode-san > output.log 2>&1); check b64_decode: Assertion `dest && targsize > 0' failed. - $ test-b64_encode-san > output.log 2>&1; check + $ $(test-b64_encode-san > output.log 2>&1); check b64_encode: Assertion `dest && targsize > 0' failed. -- 2.30.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v1 2/2] libubox: tests: add more blobmsg/json test cases
Hello Petr, On Sun, 7 Mar 2021 11:30:28 +0100, Petr Štetiar wrote: > Peter Seiderer [2021-03-06 11:54:50]: > > Hi, > > nice, just a small nitpicks, these seems fine: > > > + int8_max: 127 > > + int8_min: -128 > > ... > > but the outputs bellow looks suspicious: > > > + [*] blobmsg from json: > > ... > > > + int8_max: 1 > > + int8_min: 1 > > ... > > > + [*] blobmsg from json/cast_u64: > > ... > > > + int8_max: 1 > > + int8_min: 1 > > ... > > > + [*] blobmsg from json/cast_s64: > > ... > > > + int8_max: 1 > > + int8_min: 1 As stated/hidden in the test case source code: /* u8 is converted to boolean (true: all values != 0/false: value 0) in json */ See [1] from the libubox source code... Regards, Peter [1] https://git.openwrt.org/?p=project/libubox.git;a=blob;f=blobmsg_json.c;h=dce81e991ef7b83ac4906bca6f875369d3057f36;hb=HEAD#l254 > > Cheers, > > Petr > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v1 1/2] libubox: fix test_base64.t for bash
Hello Petr,
On Sun, 7 Mar 2021 11:27:11 +0100, Petr Štetiar wrote:
> Peter Seiderer [2021-03-06 11:54:49]:
>
> Hi,
>
> thanks a lot for your nice contribution!
>
> > My shell/bash seems to emit a more detailed failure message than
> > expected. Fix this by complete avoiding the failure message using
> > command substitution instead of direct command execution.
>
> This needs more work as it fails now on my development machine and it would
> fail on CI as well[1].
>
> You've two options to test your changes from the CI perspective.
>
> 1. Directly on GitLab
>
> - fork the https://gitlab.com/openwrt/project/libubox project under your
> account
> - push the changes to that forked repo of yours
> - CI kicks in automatically and it will use GitLab resources to CI test the
>changes
>
> 2. Locally with Docker container
>
> (these are basically the steps done on GitLab CI)
>
> $ git clone git://git.openwrt.org/project/libubox.git; cd libubox
> $ wget -q https://gitlab.com/ynezz/openwrt-ci/raw/master/Makefile -O
> Makefile.ci
> $ make ci-prepare -f Makefile.ci
> $ docker run --rm --tty --interactive \
> --volume $(pwd):/home/build/openwrt \
> --env CI_ENABLE_UNIT_TESTING=1 \
> registry.gitlab.com/ynezz/openwrt-ci/native-testing:latest \
> make ci-native-checks -f Makefile.ci
>
> That `ci-native-checks` target is pipeline[2] of following checks:
>
> ci-native-cppcheck - build with cppcheck static analyzer
> ci-native-scan-build - build with clang's static analyzer
> ci-native-build - build with gcc 8 9 10 and clang 10
>
>- gcc 8/9/10 runs only compile(release,debug)/cram/shunit2 tests
>- clang 10 runs sanitizer and fuzzer tests in addition to
> compile(release,debug)/cram/shunit2 tests
>
Thanks for the detailed instructions, was able to reproduce the failure,
seems it is a divergence between bash and dash (the default /bin/sh
with ubuntu) and my workaround is not working with dash..., but I can
fix the tests for my local run by explicit setting dash for the cram
run (without breaking the docker one) by:
diff --git a/tests/cram/CMakeLists.txt b/tests/cram/CMakeLists.txt
index bebd821..89c868c 100644
--- a/tests/cram/CMakeLists.txt
+++ b/tests/cram/CMakeLists.txt
@@ -14,7 +14,7 @@ ADD_CUSTOM_TARGET(prepare-cram-venv ALL DEPENDS
${PYTHON_VENV_CRAM})
ADD_TEST(
NAME cram
- COMMAND ${PYTHON_VENV_CRAM} ${test_cases}
+ COMMAND ${PYTHON_VENV_CRAM} --shell /bin/dash ${test_cases}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)
Regards,
Peter
> 1. https://gitlab.com/ynezz/openwrt-libubox/-/jobs/1078074565#L1583
> 2. https://gitlab.com/ynezz/openwrt-ci/#available-make-targets
>
> Cheers,
>
> Petr
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: libubox: How to terminate uloop orderly?
Hello Alexander,
On Tue, 17 May 2022 12:37:00 +0300, Alexandru Ardelean
wrote:
> On Tue, May 17, 2022 at 12:06 PM Koch, Alexander via openwrt-devel
> wrote:
> >
> > The sender domain has a DMARC Reject/Quarantine policy which disallows
> > sending mailing list messages using the original "From" header.
> >
> > To mitigate this problem, the original message has been wrapped
> > automatically by the mailing list software.
> >
> >
> > -- Forwarded message --
> > From: "Koch, Alexander"
> > To: "openwrt-devel@lists.openwrt.org"
> > Cc:
> > Bcc:
> > Date: Tue, 17 May 2022 09:04:13 +
> > Subject: libubox: How to terminate uloop orderly?
> > Hi openwrt-devel,
> >
> > I'm writing a small daemon in C that talks to a specific IC and shall offer
> > its
> > functionality to other OpenWRT components via ubus.
> >
> > It spawns a separate pthread for all ubus related things, which ends up
> > calling
> > `uloop_run()`. So far everything works fine and I can see all objects
> > exposed by
> > my daemon on the bus.
> >
> > The issue I'm facing now is that I cannot seem to find a way of orderly
> > shutting
> > down the daemon, as the thread calling `uloop_run()` never returns from it.
> > I've
> > tried calling `uloop_end()` as well as replacing `uloop_run()` by
> > `uloop_run_timeout(10)` but that didn't help.
>
> I never thought/knew that uloop_run() & threads mixed well.
> I never tried it too much either.
>
> I always thought of uloop_run() being the main process loop and then
> "maybe" starting some threads from there.
> And I think uloop is kind of designed to be more single-process than
> multi-process.
>
> So, if you have one uloop somewhere and try to do some uloop calls in
> a thread, it's kind of race-y and potentially buggy.
> Also because they work on the same main loop data.
>
> >
> > So I'm wondering: what is the correct way to terminate the uloop?
> >
> > One thing that does seem to work is sending the thread a SIGTERM via
> > `pthread_kill()`. But that makes `uloop_run()` return a non-zero value (15)
> > and,
> > as signals are delivered to the entire process, can have side-effects on
> > other
> > parts of the daemon, so I'd prefer to avoid this method.
> >
Despite the mentioned multi-threading problems with this approach
one option to stop the uloop_run() call from another thread is by
calling:
uloop_handle_sigint(SIGTERM)
But needs a patched libubox to get public access to this method, e.g.:
diff --git a/uloop.c b/uloop.c
index 8517366..b7cc764 100644
--- a/uloop.c
+++ b/uloop.c
@@ -402,7 +402,7 @@ static void uloop_signal_wake(void)
} while (1);
}
-static void uloop_handle_sigint(int signo)
+void uloop_handle_sigint(int signo)
{
uloop_status = signo;
uloop_cancelled = true;
diff --git a/uloop.h b/uloop.h
index 36084f5..ab061a5 100644
--- a/uloop.h
+++ b/uloop.h
@@ -112,4 +112,7 @@ static inline int uloop_run(void)
}
void uloop_done(void);
+
+void uloop_handle_sigint(int signo);
+
#endif
Regards,
Peter
> >
> > Thanks in advance for any hints!
> >
> >
> > Best regards,
> >
> > Alex
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uqmi v1] uqmi: avoid gcc false error reporting (storing the address of local variable 'complete' in '*req.complete')
Avoid gcc false error reporting (req->complete is later reset to NULL
in case of use of local complete):
dev.c:217:23: error: storing the address of local variable 'complete' in
'*req.complete' [-Werror=dangling-pointer=]
217 | req->complete = &complete;
| ~~^~~~~~~
Signed-off-by: Peter Seiderer
---
dev.c | 12
1 file changed, 12 insertions(+)
diff --git a/dev.c b/dev.c
index bd10207..b8ac273 100644
--- a/dev.c
+++ b/dev.c
@@ -203,6 +203,15 @@ void qmi_request_cancel(struct qmi_dev *qmi, struct
qmi_request *req)
__qmi_request_complete(qmi, req, NULL);
}
+/* avoid gcc false error reporting:
+ * dev.c:217:23: error: storing the address of local variable ‘complete’ in
‘*req.complete’ [-Werror=dangling-pointer=]
+ * 217 | req->complete = &complete;
+ * | ~~^~~
+ */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdangling-pointer"
+#endif
int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
{
bool complete = false;
@@ -231,6 +240,9 @@ int qmi_request_wait(struct qmi_dev *qmi, struct
qmi_request *req)
return req->ret;
}
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
+#pragma GCC diagnostic pop
+#endif
struct qmi_connect_request {
struct qmi_request req;
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uqmi v2] uqmi: avoid gcc-12.x false error reporting (storing the address of local variable 'complete' in '*req.complete')
Avoid gcc-12.x false error reporting (req->complete is later reset to NULL
in case of use of local complete):
dev.c:217:23: error: storing the address of local variable 'complete' in
'*req.complete' [-Werror=dangling-pointer=]
217 | req->complete = &complete;
| ~~^~~~~~~
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- apply pragma ignored only for gcc >= 12.x (as the warning
'-Wdangling-pointer' was introduced with gcc-12.x)
---
dev.c | 12
1 file changed, 12 insertions(+)
diff --git a/dev.c b/dev.c
index bd10207..dbd42d4 100644
--- a/dev.c
+++ b/dev.c
@@ -203,6 +203,15 @@ void qmi_request_cancel(struct qmi_dev *qmi, struct
qmi_request *req)
__qmi_request_complete(qmi, req, NULL);
}
+/* avoid gcc-12.x false error reporting:
+ * dev.c:217:23: error: storing the address of local variable ‘complete’ in
‘*req.complete’ [-Werror=dangling-pointer=]
+ * 217 | req->complete = &complete;
+ * | ~~^~~
+ */
+#if __GNUC__ >= 12
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdangling-pointer"
+#endif
int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
{
bool complete = false;
@@ -231,6 +240,9 @@ int qmi_request_wait(struct qmi_dev *qmi, struct
qmi_request *req)
return req->ret;
}
+#if __GNUC__ >= 12
+#pragma GCC diagnostic pop
+#endif
struct qmi_connect_request {
struct qmi_request req;
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
