| Products > Programming |
| GCC v11 32F4: compiler warning depends on optimisation level |
| (1/13) > >> |
| peter-h:
This function produces no warning with -Og or -Os but with most others e.g. -O1 you get 'ipaddr.addr' may be used uninitialized in this function [-Wmaybe-uninitialized] line 182 How does that work? |
| Nominal Animal:
Such "maybe" warnings are based on the pattern in the intermediate representation (GIMPLE or GENERIC for GCC) after optimizations are applied, and are heuristic instead of deterministic. In your case, ipaddr indeed is used uninitialized if the value does not conform to numeric IPv4 dotted notation. Initializing it to all zeros would make a lot of sense in my opinion. |
| SiliconWizard:
As Nominal said, it does depend on the internal representation the compilers makes, but I would see it as a limitation of its static analyzer, which is still not very good for GCC. The CLang one is better. You simply have execution paths for which ipaddr is not set (if both sscanf fail), and the function returns this variable it in all cases. So the warning is definitely relevant. The fact it only appears in some optimization levels isn't great IMHO, but would again be explained with how GCC handles it internally. You should initialize ipaddr to some default value. Not sure what the type is, but simply: ip_addr_t ipaddr = {}; should do (I think formally it's only correct in recent standard revisions - maybe strictly C2x? - but GCC has been accepting that for a long time for initializing almost anything to '0'). I would suggest avoiding sscanf() too here, ideally. Not only is it relatively expensive (both in terms of code size and execution time), but it's also pretty unsafe. |
| coppice:
What platform is this? IP4_ADDR is usually a macro. So, depending exactly what that macro contains, ipaddr.addr might we well be used undefined. |
| golden_labels:
Extending what Nominal Animal said about such best-effort warnings, -Og disables dead store elimination which is otherwise enabled. We may speculate, what is going on. Most notably that the difference lies outside ▒▒▒_netconf_get_ip_config_value. Variable ipaddr is allocated not in this function, but in its caller. Something in the caller writes over storage used by ipaddr, which is ignored with DSE enabled (hence seen as uninitialized), but is not ignored with DSE disabled (hence seen as initialized, even if not intentionally). That may be separate from the logical error in this function itself, where an execution path exists allowing ipaddr to never be set before being returned. |
| Navigation |
| Message Index |
| Next page |