On 10.07.19 22:50, Philippe Gerum wrote:
> On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
>> From: Jan Kiszka <jan.kis...@siemens.com>
>>
>> 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 <sance...@numalliance.com>
>> Reported-by: Cris Almaraz <cristina.alma...@gmail.com>
>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>> ---
>>
>> 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
