Code gives: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
matthijskooijman opened this issue · comments
Describe the bug
When compiling the ttn-otaa example with the current git master, and warnings enabled in the IDE, I get a ton of warnings like this one:
/home/matthijs/docs/Electronics/Arduino/Sketches/libraries/mcci-lmic/src/lmic/config.h:22:5: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
#if CFG_LMIC_REGION_MASK == 0
^~~~~~~~~~~~~~~~~~~~
I think this warning was added in a recent compiler upgrade.
This comes from this macro definition:
# define CFG_LMIC_REGION_MASK \
((defined(CFG_eu868) << LMIC_REGION_eu868) | \
(defined(CFG_us915) << LMIC_REGION_us915) | \
(defined(CFG_cn783) << LMIC_REGION_cn783) | \
(defined(CFG_eu433) << LMIC_REGION_eu433) | \
(defined(CFG_au915) << LMIC_REGION_au915) | \
(defined(CFG_cn490) << LMIC_REGION_cn490) | \
(defined(CFG_as923) << LMIC_REGION_as923) | \
(defined(CFG_kr920) << LMIC_REGION_kr920) | \
(defined(CFG_in866) << LMIC_REGION_in866) | \
0)
which, when used in an #if
, gives non-portable behavior. It is easy to fix, though, I think something like this should be equivalent but without the warning:
# if \
((defined(CFG_eu868) << LMIC_REGION_eu868) | \
(defined(CFG_us915) << LMIC_REGION_us915) | \
(defined(CFG_cn783) << LMIC_REGION_cn783) | \
(defined(CFG_eu433) << LMIC_REGION_eu433) | \
(defined(CFG_au915) << LMIC_REGION_au915) | \
(defined(CFG_cn490) << LMIC_REGION_cn490) | \
(defined(CFG_as923) << LMIC_REGION_as923) | \
(defined(CFG_kr920) << LMIC_REGION_kr920) | \
(defined(CFG_in866) << LMIC_REGION_in866) | \
0)
# define CFG_LMIC_REGION_MASK 1
# else
# define CFG_LMIC_REGION_MASK 1
# endif
(haven't tested, though).
Similar warnings (with I presume similar fixes) happen for e.g. CFG_LMIC_EU_like
and friends.
Environment
- Version of LMIC being used: 89c28c5
- Version of Arduino IDE being used: 1.8.13-ish (manually compiled git), AVR core 1.8.2.
To Reproduce
Compile the ttn-otaa example with warnings enabled in the IDE preferences
Yep, that's a problem; too clever by half. I'll look at this as part of the secure element (#578) refactoring merge that's coming up. I'm still in the six months of horribly busy with the day job phase of my life that corresponded with the pandemic; I'm beginning to see daylight but...
Ok! No hurry, it's just goldplating :-)