On 10.07.19 22:50, Philippe Gerum wrote: > On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote: >> From: Jan Kiszka <[email protected]> >> >> This was ignored by most compilers so far, but it breaks at least under >> c++11. > > This was hardly ignored since this evaluates to a required type > information, the issue is rather with typeof() belonging to the GNU > extension set. Building with -std=gnu++11 solves that issue with the > current implementation which generally assumes those extensions are enabled.
If these two cases are the only ones that prevent standard-conforming builds ouf our external headers, I would be in favor of overcoming that limitation. But if it should be just the tip of the iceberg, it's likely not worth it. > >> >> Reported-by: Stéphane Ancelot <[email protected]> >> Reported-by: Cris Almaraz <[email protected]> >> Signed-off-by: Jan Kiszka <[email protected]> >> --- >> >> Thanks for reporting (and sorry for the long patch delay). This should >> fix it. >> >> include/boilerplate/tunables.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h >> index db8523be67..38f414e455 100644 >> --- a/include/boilerplate/tunables.h >> +++ b/include/boilerplate/tunables.h >> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void) >> __read_ ## __name ## _ ## __scope >> >> #define __define_tunable(__name, __type, __val, __scope) \ >> - void __tunable_set_call(__name, __scope)(typeof(__type) __val) >> + void __tunable_set_call(__name, __scope)(__type __val) >> >> #define __read_tunable(__name, __type, __scope) \ >> - typeof(__type) __tunable_get_call(__name, __scope)(void) >> + __type __tunable_get_call(__name, __scope)(void) >> >> #define define_config_tunable(__name, __type, __val) \ >> __define_tunable(__name, __type, __val, config) >> -- > > > That won't work with non-trivial type expr like this one: > > int (*foo_handler)(void); > > define_config_tunable(foobar, int (*)(void), handler) > { > foo_handler = handler; > } > > And we have those in the field already. > Out of tree? I didn't find any in-tree build issues. Jan
