Remove build warnings in LWIP #5319

kegilbert · 2017-10-13T22:26:46Z

Addresses #5318

Project built in exported projects (tested with make_armc5 in particular) or on the online compiler will generate a good amount of build warnings. These small fixes should resolve the LWIP warnings (and add error checking on ppp_lwip_disconnect calls).

theotherjimmy · 2017-10-16T19:01:36Z

@kegilbert Why are these warnings only in the online compiler and exporters and not by the build system. Is there a deficiency somewhere?

kegilbert · 2017-10-16T19:16:45Z

Spoke offline with @theotherjimmy, warnings were showing up in the short form on local builds, had managed to miss them earlier. Updated title to reflect.

0xc0170 · 2017-10-17T13:40:15Z

features/FEATURE_LWIP/lwip-interface/lwip_stack.c

@@ -658,7 +660,10 @@ nsapi_error_t mbed_lwip_bringup_2(bool dhcp, bool ppp, const char *ip, const cha
    if (!netif_is_link_up(&lwip_netif)) {
        if (sys_arch_sem_wait(&lwip_netif_linked, 15000) == SYS_ARCH_TIMEOUT) {
            if (ppp) {
-                ppp_lwip_disconnect();
+                err_t err = ppp_lwip_disconnect();
+                if(err != ERR_OK) {


if () - space between as in the rest of this file

0xc0170 · 2017-10-17T13:40:32Z

cc @kjbracey-arm

kjbracey · 2017-10-18T07:35:36Z

CC @mikaleppanen

kjbracey · 2017-10-18T07:36:34Z

features/FEATURE_LWIP/lwip-interface/lwip_stack.c

@@ -658,7 +660,10 @@ nsapi_error_t mbed_lwip_bringup_2(bool dhcp, bool ppp, const char *ip, const cha
    if (!netif_is_link_up(&lwip_netif)) {
        if (sys_arch_sem_wait(&lwip_netif_linked, 15000) == SYS_ARCH_TIMEOUT) {
            if (ppp) {
-                ppp_lwip_disconnect();
+                err_t err = ppp_lwip_disconnect();


Not sure about this and the similar change below - I think we always want to return NSAPI_ERROR_NO_CONNECTION, not whatever oddities PPP might throw up during attempted shutdown.

mikaleppanen · 2017-10-18T07:45:29Z

features/FEATURE_LWIP/lwip-interface/lwip_stack.c

@@ -293,7 +293,9 @@ static int get_ip_addr_type(const ip_addr_t *ip_addr)
        return IPADDR_TYPE_V4;
    }
 #endif
+#if !LWIP_IPV6 && !LWIP_IPV4


Should this be "#if LWIP_IPV6 && LWIP_IPV4"

As in this?

#if LWIP_IPV6 && LWIP_IPV4 return IP_ADDR_ANY; #if LWIP_IPV4 .... #if LWIP_IPV6 ...

I'm honestly not sure what the original intention was, the way it was written seemed to be only return IP_ADDR_ANY if neither LWIP_IPV4 or LWIP_IPV6 was enabled, but the name IP_ADDR_ANY sounds like it should be if both are enabled.

IP_IS_V6/IP_IS_V4 defines do something (other than evaluate to true) only when both LWIP_IPV6 and LWIP_IPV4 flags are enabled. Also disabling both LWIP_IPV6 and LWIP_IPV4 is not valid configuration and will return compilation error. So, the function can reach the return at the end only in dual ipv4v6 configuration.

Currently get_ip_addr_type() function is used by add dns address function and it is not made to be fully general utility function. That is because the dns function calling it never uses it to evaluate address that type is any, and is interested only whether address is either ipv4 or ipv6.

If function would be made more general, there could be also evolution under LWIP_IPV6 && LWIP_IPV4 flags to return IP_ADDR_ANY only in case address type really is any. And to return -1 or some other error, in case address type is not valid at all (field is somehow corrupted).

But I think that since currently this function is used only for purposes of add dns address, adding the above evaluations are not needed and flagging the return with LWIP_IPV6 && LWIP_IPV4 flags is enough.

At this point, I'd be inclined to put a pragma in to shut the compiler up. The ifdefs already in that function are excessive - presumably they're to silence a "constant expression in condition"?

Given the form of the lwIP dual IPv4/v6 code, silencing "unreachable code" and "constant expression" would allow you to just freely use those IS_V4/IS_V6 macros without it getting in the way.

(The Linux kernel is built with those warnings disabled, because there are a lot of similar macros that can either be constant or variable depending on config switches).

In libservice's ns_types.h, you can see NS_DUMMY_DEFINITIONS_OK, which attempts to disable some of them...

Using pragma is ok for me. Yes, I agree that it is not very good that we have these IP_IS_V6/IP_IS_V4 etc. defines that would allow to write clear code that works with all configurations, but because of compiler warnings we need to use ifdefs also when using macros and not just when defining them.

kegilbert · 2017-10-18T16:56:07Z

Error case now returned NSAPI_ERROR_NO_CONNECTION rather than the converted error code from ppp_lwip_disconnect()

kjbracey · 2017-10-19T07:13:23Z

Yes, the connection has failed, which is why it's calling ppp_lwip_disconnect() to clean up before returning NO_CONNECTION. I think we want to return NO_CONNECTION, even if the PPP disconnect throws up its own error.

kjbracey · 2017-10-19T07:16:00Z

Oh, I see you've changed it to check the return and literally return "NO_CONNECTION". No, I mean that we don't care what the ppp_disconnect returns. We're already on our way to return NO_CONNECTION or DHCP_FAILURE.

If you need to silence a warning or Coverity diagnostic, you could just stick a (void) in front of it, I guess?

adbridge · 2017-10-24T15:24:34Z

@kegilbert Can you address Kevin's comments please

kegilbert · 2017-10-24T23:55:43Z

Sorry the delay, updated the PR @kjbracey-arm

adbridge · 2017-10-31T15:43:18Z

@kjbracey-arm are you happy with the update ?

kjbracey · 2017-11-01T09:30:45Z

features/FEATURE_LWIP/lwip-interface/lwip_stack.c

@@ -283,6 +283,9 @@ static void add_dns_addr_to_dns_list_index(const u8_t addr_type, const u8_t inde

 static int get_ip_addr_type(const ip_addr_t *ip_addr)
 {
+#if LWIP_IPV6 && LWIP_IPV4


This isn't correct - if it's going to be done like this, it needs to be at the end - the return remains in the same place, but with the added #if to shut the compiler up.

@kjbracey-arm Updated in last commit.

theotherjimmy · 2017-11-02T15:31:18Z

/morph build

mbed-ci · 2017-11-02T16:02:15Z

Build : FAILURE

Build number : 416
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5319/

studavekar · 2017-11-06T04:22:46Z

/morph build

mbed-ci · 2017-11-06T04:53:36Z

Build : SUCCESS

Build number : 435
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5319/

Triggering tests

/morph test
/morph uvisor-test

mbed-ci · 2017-11-06T06:09:16Z

Test : FAILURE

Build number : 243
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5319/243

studavekar · 2017-11-06T20:13:40Z

/morph test

mbed-ci · 2017-11-07T04:14:16Z

Test : FAILURE

Build number : 260
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5319/260

mbed-ci · 2017-11-08T04:45:20Z

Test : SUCCESS

Build number : 270
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5319/270

kegilbert requested review from 0xc0170 and sarahmarshy October 13, 2017 22:26

adbridge added the needs: review label Oct 16, 2017

adbridge requested a review from theotherjimmy October 16, 2017 15:19

kegilbert changed the title ~~Remove build warnings from online compiler and exported projects in LWIP~~ Remove build warnings in LWIP Oct 16, 2017

0xc0170 reviewed Oct 17, 2017

View reviewed changes

kegilbert force-pushed the fix-build-warnings branch 2 times, most recently from 9aec598 to 4d858ee Compare October 17, 2017 16:04

kjbracey reviewed Oct 18, 2017

View reviewed changes

mikaleppanen reviewed Oct 18, 2017

View reviewed changes

kegilbert force-pushed the fix-build-warnings branch from 4d858ee to 16cb9e4 Compare October 18, 2017 16:54

kegilbert force-pushed the fix-build-warnings branch from 16cb9e4 to ba0fa98 Compare October 24, 2017 23:55

kjbracey suggested changes Nov 1, 2017

View reviewed changes

Remove build warnings in LWIP

5498054

kegilbert force-pushed the fix-build-warnings branch from ba0fa98 to 5498054 Compare November 1, 2017 13:48

kjbracey approved these changes Nov 1, 2017

View reviewed changes

theotherjimmy approved these changes Nov 2, 2017

View reviewed changes

theotherjimmy added needs: CI and removed needs: review labels Nov 2, 2017

0xc0170 added ready for merge release-version: 5.6.5 and removed needs: CI labels Nov 8, 2017

0xc0170 merged commit 8acf00a into ARMmbed:master Nov 9, 2017

0xc0170 removed the ready for merge label Nov 9, 2017

Remove build warnings in LWIP #5319

Remove build warnings in LWIP #5319

Uh oh!

Conversation

kegilbert commented Oct 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theotherjimmy commented Oct 16, 2017

Uh oh!

kegilbert commented Oct 16, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Oct 17, 2017

Uh oh!

kjbracey commented Oct 18, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kegilbert Oct 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kegilbert commented Oct 18, 2017

Uh oh!

kjbracey commented Oct 19, 2017

Uh oh!

kjbracey commented Oct 19, 2017

Uh oh!

adbridge commented Oct 24, 2017

Uh oh!

kegilbert commented Oct 24, 2017

Uh oh!

adbridge commented Oct 31, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

theotherjimmy commented Nov 2, 2017

Uh oh!

mbed-ci commented Nov 2, 2017

Uh oh!

studavekar commented Nov 6, 2017

Uh oh!

mbed-ci commented Nov 6, 2017

Triggering tests

Uh oh!

mbed-ci commented Nov 6, 2017

Uh oh!

studavekar commented Nov 6, 2017

Uh oh!

mbed-ci commented Nov 7, 2017

Uh oh!

mbed-ci commented Nov 8, 2017

Uh oh!

Uh oh!

kegilbert commented Oct 13, 2017 •

edited

Loading

kegilbert Oct 18, 2017 •

edited

Loading