Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 04:18 PM, git repository hosting wrote:
> Module: xenomai-jki
> Branch: for-forge
> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
> URL:    http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Tue Feb  4 16:12:07 2014 +0100
>
> alchemy: Replace static variable no_alchemy_task with macro
>
> The current definition of a static const variable representing an
> invalid alchemy task is both C++-incompatible and also ugly as we do not
> use them in every module that includes task.h. So replace it with a
> macro that builds the required struct on-the-fly.

Well, this structure is valid C99, is not there any way to get the C++ 
compiler to accept it ? Like -std=c++11 ?


-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 04:18 PM, git repository hosting wrote:
> Module: xenomai-jki
> Branch: for-forge
> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
> URL:    http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Tue Feb  4 16:12:07 2014 +0100
>
> alchemy: Replace static variable no_alchemy_task with macro
>
> The current definition of a static const variable representing an
> invalid alchemy task is both C++-incompatible and also ugly as we do not
> use them in every module that includes task.h. So replace it with a
> macro that builds the required struct on-the-fly.

Could you elaborate on the ugly part of things? I don't really get your 
point.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 17:36, Philippe Gerum wrote:
> On 02/04/2014 04:18 PM, git repository hosting wrote:
>> Module: xenomai-jki
>> Branch: for-forge
>> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>> URL:   
>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>
>>
>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>> Date:   Tue Feb  4 16:12:07 2014 +0100
>>
>> alchemy: Replace static variable no_alchemy_task with macro
>>
>> The current definition of a static const variable representing an
>> invalid alchemy task is both C++-incompatible and also ugly as we do not
>> use them in every module that includes task.h. So replace it with a
>> macro that builds the required struct on-the-fly.
> 
> Could you elaborate on the ugly part of things? I don't really get your
> point.

It is ugly to define potentially unused static variables in a header,
even more when this header is part of the public interface, pulled in by
our users with hard to predict compiler configurations. But more
important is the conflict with C++ (including C++11).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 06:12 PM, Jan Kiszka wrote:
> On 2014-02-04 17:36, Philippe Gerum wrote:
>> On 02/04/2014 04:18 PM, git repository hosting wrote:
>>> Module: xenomai-jki
>>> Branch: for-forge
>>> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>> URL:
>>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>>
>>>
>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>> Date:   Tue Feb  4 16:12:07 2014 +0100
>>>
>>> alchemy: Replace static variable no_alchemy_task with macro
>>>
>>> The current definition of a static const variable representing an
>>> invalid alchemy task is both C++-incompatible and also ugly as we do not
>>> use them in every module that includes task.h. So replace it with a
>>> macro that builds the required struct on-the-fly.
>>
>> Could you elaborate on the ugly part of things? I don't really get your
>> point.
>
> It is ugly to define potentially unused static variables in a header,
> even more when this header is part of the public interface, pulled in by
> our users with hard to predict compiler configurations.

This is a const static, exposed as a common definition, which normally 
has no existence in the data segment when built with g++ 4.x. Not even 
with -O0.

So maybe you could tell us which is the exact issue you have beyond the 
struct initializer issue, and the compiler release you are currently 
using, along with the build flags?

But more
> important is the conflict with C++ (including C++11).
>

If g++ chokes on the initializer part because it is outdated, then using 
old-fashioned ones may be an option. Actually, I find macroizing this 
definition quite bad.

static const RT_TASK no_alchemy_task = {
-	.handle = 0,
-	.thread = 0
+	handle: 0,
+	thread: 0
  };

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 06:27 PM, Philippe Gerum wrote:
> If g++ chokes on the initializer part because it is outdated, then using
> old-fashioned ones may be an option. Actually, I find macroizing this
> definition quite bad.
>
> static const RT_TASK no_alchemy_task = {
> -	.handle = 0,
> -	.thread = 0
> +	handle: 0,
> +	thread: 0
>    };

No, the previous version is better, it is standard compliant C and C++, 
the second version is a gcc extension, which works only when compiling 
C, if I remember correctly.

-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 18:32, Gilles Chanteperdrix wrote:
> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>> If g++ chokes on the initializer part because it is outdated, then using
>> old-fashioned ones may be an option. Actually, I find macroizing this
>> definition quite bad.
>>
>> static const RT_TASK no_alchemy_task = {
>> -    .handle = 0,
>> -    .thread = 0
>> +    handle: 0,
>> +    thread: 0
>>    };
> 
> No, the previous version is better, it is standard compliant C and C++,
> the second version is a gcc extension, which works only when compiling
> C, if I remember correctly.

Designated initializer are _not_ standard compliant. If newer g++ accept
them, that's luck but nothing we can rely on. User may decide to write
compliant code...

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 06:35 PM, Jan Kiszka wrote:
> On 2014-02-04 18:32, Gilles Chanteperdrix wrote:
>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>> If g++ chokes on the initializer part because it is outdated, then using
>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>> definition quite bad.
>>>
>>> static const RT_TASK no_alchemy_task = {
>>> -    .handle = 0,
>>> -    .thread = 0
>>> +    handle: 0,
>>> +    thread: 0
>>>     };
>>
>> No, the previous version is better, it is standard compliant C and C++,
>> the second version is a gcc extension, which works only when compiling
>> C, if I remember correctly.
>
> Designated initializer are _not_ standard compliant.

They are standard in C99 at least. I thought they were in C++0x as well, 
but googling a bit would seem to suggest that you are right.


-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>> If g++ chokes on the initializer part because it is outdated, then using
>> old-fashioned ones may be an option. Actually, I find macroizing this
>> definition quite bad.
>>
>> static const RT_TASK no_alchemy_task = {
>> -    .handle = 0,
>> -    .thread = 0
>> +    handle: 0,
>> +    thread: 0
>>    };
>
> No, the previous version is better, it is standard compliant C and C++,
> the second version is a gcc extension, which works only when compiling
> C, if I remember correctly.
>

Recent g++ is happy with both (no -std forced though). But the former is 
allowed by the C++ parser only since recently.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 06:39 PM, Philippe Gerum wrote:
> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>> If g++ chokes on the initializer part because it is outdated, then using
>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>> definition quite bad.
>>>
>>> static const RT_TASK no_alchemy_task = {
>>> -    .handle = 0,
>>> -    .thread = 0
>>> +    handle: 0,
>>> +    thread: 0
>>>     };
>>
>> No, the previous version is better, it is standard compliant C and C++,
>> the second version is a gcc extension, which works only when compiling
>> C, if I remember correctly.
>>
>
> Recent g++ is happy with both (no -std forced though). But the former is
> allowed by the C++ parser only since recently.
>

Well, on the other hand:
static const RT_TAKS no_alchemy_task;

Will zero initialized the structure just as well...

-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 18:44, Gilles Chanteperdrix wrote:
> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>> If g++ chokes on the initializer part because it is outdated, then
>>>> using
>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>> definition quite bad.
>>>>
>>>> static const RT_TASK no_alchemy_task = {
>>>> -    .handle = 0,
>>>> -    .thread = 0
>>>> +    handle: 0,
>>>> +    thread: 0
>>>>     };
>>>
>>> No, the previous version is better, it is standard compliant C and C++,
>>> the second version is a gcc extension, which works only when compiling
>>> C, if I remember correctly.
>>>
>>
>> Recent g++ is happy with both (no -std forced though). But the former is
>> allowed by the C++ parser only since recently.
>>
> 
> Well, on the other hand:
> static const RT_TAKS no_alchemy_task;
> 
> Will zero initialized the structure just as well...

True, but older g++ will complain about unused variable. I've seen this
with 4.5, currently checking a newer version.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>> If g++ chokes on the initializer part because it is outdated, then
>>>> using
>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>> definition quite bad.
>>>>
>>>> static const RT_TASK no_alchemy_task = {
>>>> -    .handle = 0,
>>>> -    .thread = 0
>>>> +    handle: 0,
>>>> +    thread: 0
>>>>     };
>>>
>>> No, the previous version is better, it is standard compliant C and C++,
>>> the second version is a gcc extension, which works only when compiling
>>> C, if I remember correctly.
>>>
>>
>> Recent g++ is happy with both (no -std forced though). But the former is
>> allowed by the C++ parser only since recently.
>>
>
> Well, on the other hand:
> static const RT_TAKS no_alchemy_task;
>
> Will zero initialized the structure just as well...
>

In that case you will have the object exist in the .bss.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 06:48 PM, Philippe Gerum wrote:
> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>> using
>>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>>> definition quite bad.
>>>>>
>>>>> static const RT_TASK no_alchemy_task = {
>>>>> -    .handle = 0,
>>>>> -    .thread = 0
>>>>> +    handle: 0,
>>>>> +    thread: 0
>>>>>     };
>>>>
>>>> No, the previous version is better, it is standard compliant C and C++,
>>>> the second version is a gcc extension, which works only when compiling
>>>> C, if I remember correctly.
>>>>
>>>
>>> Recent g++ is happy with both (no -std forced though). But the former is
>>> allowed by the C++ parser only since recently.
>>>
>>
>> Well, on the other hand:
>> static const RT_TAKS no_alchemy_task;
>>
>> Will zero initialized the structure just as well...
>>
>
> In that case you will have the object exist in the .bss.
>

It turns out that old gcc 4.x releases will create a private bss entry 
for this symbol in any case, which recent ones won't produce regardless 
of the optimizing level (unless I messed up with nm, but it does not 
seem so).

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 18:53, Philippe Gerum wrote:
> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>>> using
>>>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>>>> definition quite bad.
>>>>>>
>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>> -    .handle = 0,
>>>>>> -    .thread = 0
>>>>>> +    handle: 0,
>>>>>> +    thread: 0
>>>>>>     };
>>>>>
>>>>> No, the previous version is better, it is standard compliant C and
>>>>> C++,
>>>>> the second version is a gcc extension, which works only when compiling
>>>>> C, if I remember correctly.
>>>>>
>>>>
>>>> Recent g++ is happy with both (no -std forced though). But the
>>>> former is
>>>> allowed by the C++ parser only since recently.
>>>>
>>>
>>> Well, on the other hand:
>>> static const RT_TAKS no_alchemy_task;
>>>
>>> Will zero initialized the structure just as well...
>>>
>>
>> In that case you will have the object exist in the .bss.
>>
> 
> It turns out that old gcc 4.x releases will create a private bss entry
> for this symbol in any case, which recent ones won't produce regardless
> of the optimizing level (unless I messed up with nm, but it does not
> seem so).
> 

Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code will be
the same anyway.

BTW, there are way more issues with C++ when enabling standard
compliance. Not sure where all the errors come from and if they easy to
fixing. But I think we should try to be as clean as possible in out
external interfaces.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 19:03, Jan Kiszka wrote:
> BTW, there are way more issues with C++ when enabling standard
> compliance. Not sure where all the errors come from and if they easy to
> fixing. But I think we should try to be as clean as possible in out
> external interfaces.

GCC-only typeof is our problem. Simply doing 

diff --git a/include/boilerplate/scope.h b/include/boilerplate/scope.h
index 2bdc747..e902a27 100644
--- a/include/boilerplate/scope.h
+++ b/include/boilerplate/scope.h
@@ -47,7 +47,7 @@ int pshared_check(void *heap, void *addr);
 
 #define __main_heap	NULL
 
-#define dref_type(t)		typeof(t)
+#define dref_type(t)		t
 #define __memoff(base, addr)	(addr)
 #define __memptr(base, off)	(off)
 #define __memchk(base, addr)	1
diff --git a/include/cobalt/wrappers.h b/include/cobalt/wrappers.h
index e0f7a63..ee1e72c 100644
--- a/include/cobalt/wrappers.h
+++ b/include/cobalt/wrappers.h
@@ -25,7 +25,7 @@
 #define __STD(call)		__real_ ## call
 #define __COBALT(call)		__cobalt_ ## call
 #define __RT(call)		__COBALT(call)
-#define COBALT_DECL(T, P)	typeof(T) __RT(P); typeof(T) __STD(P); typeof(T) __WRAP(P)
+#define COBALT_DECL(T, P)	T __RT(P); T __STD(P); T __WRAP(P)
 
 /*
  * 

fixes the C++98 build, but I bet I miss a reason why typeof is there in
the first place, right?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 07:20 PM, Jan Kiszka wrote:
> On 2014-02-04 19:03, Jan Kiszka wrote:
>> BTW, there are way more issues with C++ when enabling standard
>> compliance. Not sure where all the errors come from and if they easy to
>> fixing. But I think we should try to be as clean as possible in out
>> external interfaces.
>
> GCC-only typeof is our problem. Simply doing

What about __typeof__ ?


-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-04 19:26, Gilles Chanteperdrix wrote:
> On 02/04/2014 07:20 PM, Jan Kiszka wrote:
>> On 2014-02-04 19:03, Jan Kiszka wrote:
>>> BTW, there are way more issues with C++ when enabling standard
>>> compliance. Not sure where all the errors come from and if they easy to
>>> fixing. But I think we should try to be as clean as possible in out
>>> external interfaces.
>>
>> GCC-only typeof is our problem. Simply doing
> 
> What about __typeof__ ?

Works fine, will queue a patch.

Still, why do we have typeof in the cited cases? We know that the
parameters are types and not variables, no?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 07:35 PM, Jan Kiszka wrote:
> On 2014-02-04 19:26, Gilles Chanteperdrix wrote:
>> On 02/04/2014 07:20 PM, Jan Kiszka wrote:
>>> On 2014-02-04 19:03, Jan Kiszka wrote:
>>>> BTW, there are way more issues with C++ when enabling standard
>>>> compliance. Not sure where all the errors come from and if they easy to
>>>> fixing. But I think we should try to be as clean as possible in out
>>>> external interfaces.
>>>
>>> GCC-only typeof is our problem. Simply doing
>>
>> What about __typeof__ ?
>
> Works fine, will queue a patch.
>
> Still, why do we have typeof in the cited cases? We know that the
> parameters are types and not variables, no?
>

COBALT_DECL(int (*)(void), foo(int arg)) will do the right thing with 
typeof, but won't with a trivial preprocessor token substitution.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 07:03 PM, Jan Kiszka wrote:
> On 2014-02-04 18:53, Philippe Gerum wrote:
>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>>>> using
>>>>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>>>>> definition quite bad.
>>>>>>>
>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>> -    .handle = 0,
>>>>>>> -    .thread = 0
>>>>>>> +    handle: 0,
>>>>>>> +    thread: 0
>>>>>>>      };
>>>>>>
>>>>>> No, the previous version is better, it is standard compliant C and
>>>>>> C++,
>>>>>> the second version is a gcc extension, which works only when compiling
>>>>>> C, if I remember correctly.
>>>>>>
>>>>>
>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>> former is
>>>>> allowed by the C++ parser only since recently.
>>>>>
>>>>
>>>> Well, on the other hand:
>>>> static const RT_TAKS no_alchemy_task;
>>>>
>>>> Will zero initialized the structure just as well...
>>>>
>>>
>>> In that case you will have the object exist in the .bss.
>>>
>>
>> It turns out that old gcc 4.x releases will create a private bss entry
>> for this symbol in any case, which recent ones won't produce regardless
>> of the optimizing level (unless I messed up with nm, but it does not
>> seem so).
>>
>
> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code will be
> the same anyway.
>
> BTW, there are way more issues with C++ when enabling standard
> compliance. Not sure where all the errors come from and if they easy to
> fixing. But I think we should try to be as clean as possible in out
> external interfaces.
>

Mmm, no. I don't want to rush merging all kinds of isolated fixes for 
all sorts of pedantic modes. I see the other one following with typeof 
constructs, later we will get other changes triggered by other 
restrictions on gcc extensions, and this general trend is not 
acceptable. The fact that the external API headers still share portions 
with the implementation does not help, but this is not a reason for 
downgrading the C dialect of the latter with ugly work arounds.

If you really want to go this way, I suggest that you issue a single, 
all-in-one patch making the current code base conforming with the C/C++ 
standard you aim at, so that we have a general overview of the changes. 
With that information, we should be able to address strict standard 
conformance better, which may involve addressing the 
interface/implementation issue with headers.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-05 09:33, Philippe Gerum wrote:
> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>>>>> using
>>>>>>>> old-fashioned ones may be an option. Actually, I find macroizing
>>>>>>>> this
>>>>>>>> definition quite bad.
>>>>>>>>
>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>> -    .handle = 0,
>>>>>>>> -    .thread = 0
>>>>>>>> +    handle: 0,
>>>>>>>> +    thread: 0
>>>>>>>>      };
>>>>>>>
>>>>>>> No, the previous version is better, it is standard compliant C and
>>>>>>> C++,
>>>>>>> the second version is a gcc extension, which works only when
>>>>>>> compiling
>>>>>>> C, if I remember correctly.
>>>>>>>
>>>>>>
>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>> former is
>>>>>> allowed by the C++ parser only since recently.
>>>>>>
>>>>>
>>>>> Well, on the other hand:
>>>>> static const RT_TAKS no_alchemy_task;
>>>>>
>>>>> Will zero initialized the structure just as well...
>>>>>
>>>>
>>>> In that case you will have the object exist in the .bss.
>>>>
>>>
>>> It turns out that old gcc 4.x releases will create a private bss entry
>>> for this symbol in any case, which recent ones won't produce regardless
>>> of the optimizing level (unless I messed up with nm, but it does not
>>> seem so).
>>>
>>
>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code will be
>> the same anyway.
>>
>> BTW, there are way more issues with C++ when enabling standard
>> compliance. Not sure where all the errors come from and if they easy to
>> fixing. But I think we should try to be as clean as possible in out
>> external interfaces.
>>
> 
> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
> all sorts of pedantic modes. I see the other one following with typeof
> constructs, later we will get other changes triggered by other
> restrictions on gcc extensions, and this general trend is not
> acceptable. The fact that the external API headers still share portions
> with the implementation does not help, but this is not a reason for
> downgrading the C dialect of the latter with ugly work arounds.
> 
> If you really want to go this way, I suggest that you issue a single,
> all-in-one patch making the current code base conforming with the C/C++
> standard you aim at, so that we have a general overview of the changes.
> With that information, we should be able to address strict standard
> conformance better, which may involve addressing the
> interface/implementation issue with headers.

It's pointless to make the core standard-compliant, C or even C++. But
we are exposing an interface that definitely has to be compatible with
C++ (most of my patches) as we do not have control over the user's
toolchain and language (there would be no good reason to restrict it).
And if it is trivial to get the interface even ANSI compliant (last
patch) and also recommended by GCC to do so in libraries, what pain does
it cause to us to follow this road?

Yes, the amount of internals currently exposed via the external headers
should be optimized. But I guess this is something to be done as cleanup
once the code base, including Mercury, settled a bit more.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/05/2014 09:49 AM, Jan Kiszka wrote:
> On 2014-02-05 09:33, Philippe Gerum wrote:
>> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>>>>>> using
>>>>>>>>> old-fashioned ones may be an option. Actually, I find macroizing
>>>>>>>>> this
>>>>>>>>> definition quite bad.
>>>>>>>>>
>>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>>> -    .handle = 0,
>>>>>>>>> -    .thread = 0
>>>>>>>>> +    handle: 0,
>>>>>>>>> +    thread: 0
>>>>>>>>>       };
>>>>>>>>
>>>>>>>> No, the previous version is better, it is standard compliant C and
>>>>>>>> C++,
>>>>>>>> the second version is a gcc extension, which works only when
>>>>>>>> compiling
>>>>>>>> C, if I remember correctly.
>>>>>>>>
>>>>>>>
>>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>>> former is
>>>>>>> allowed by the C++ parser only since recently.
>>>>>>>
>>>>>>
>>>>>> Well, on the other hand:
>>>>>> static const RT_TAKS no_alchemy_task;
>>>>>>
>>>>>> Will zero initialized the structure just as well...
>>>>>>
>>>>>
>>>>> In that case you will have the object exist in the .bss.
>>>>>
>>>>
>>>> It turns out that old gcc 4.x releases will create a private bss entry
>>>> for this symbol in any case, which recent ones won't produce regardless
>>>> of the optimizing level (unless I messed up with nm, but it does not
>>>> seem so).
>>>>
>>>
>>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code will be
>>> the same anyway.
>>>
>>> BTW, there are way more issues with C++ when enabling standard
>>> compliance. Not sure where all the errors come from and if they easy to
>>> fixing. But I think we should try to be as clean as possible in out
>>> external interfaces.
>>>
>>
>> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
>> all sorts of pedantic modes. I see the other one following with typeof
>> constructs, later we will get other changes triggered by other
>> restrictions on gcc extensions, and this general trend is not
>> acceptable. The fact that the external API headers still share portions
>> with the implementation does not help, but this is not a reason for
>> downgrading the C dialect of the latter with ugly work arounds.
>>
>> If you really want to go this way, I suggest that you issue a single,
>> all-in-one patch making the current code base conforming with the C/C++
>> standard you aim at, so that we have a general overview of the changes.
>> With that information, we should be able to address strict standard
>> conformance better, which may involve addressing the
>> interface/implementation issue with headers.
>
> It's pointless to make the core standard-compliant, C or even C++. But

This has never been considered for sure.

> we are exposing an interface that definitely has to be compatible with
> C++ (most of my patches) as we do not have control over the user's
> toolchain and language (there would be no good reason to restrict it).
> And if it is trivial to get the interface even ANSI compliant (last
> patch) and also recommended by GCC to do so in libraries, what pain does
> it cause to us to follow this road?
>

The pain is that we seem to be adding more and more restrictions to the 
C dialect usable by the implementation, because of that sharing with the 
interface. This is not acceptable.

> Yes, the amount of internals currently exposed via the external headers
> should be optimized. But I guess this is something to be done as cleanup
> once the code base, including Mercury, settled a bit more.
>

This is a copperplate issue, regardless of whether you stack it over the 
dual or single kernel system, and in this respect, the copperplate API 
is stable (although I really have to document it at some point though).

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-05 09:58, Philippe Gerum wrote:
> On 02/05/2014 09:49 AM, Jan Kiszka wrote:
>> On 2014-02-05 09:33, Philippe Gerum wrote:
>>> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>>>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>>>> If g++ chokes on the initializer part because it is outdated,
>>>>>>>>>> then
>>>>>>>>>> using
>>>>>>>>>> old-fashioned ones may be an option. Actually, I find macroizing
>>>>>>>>>> this
>>>>>>>>>> definition quite bad.
>>>>>>>>>>
>>>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>>>> -    .handle = 0,
>>>>>>>>>> -    .thread = 0
>>>>>>>>>> +    handle: 0,
>>>>>>>>>> +    thread: 0
>>>>>>>>>>       };
>>>>>>>>>
>>>>>>>>> No, the previous version is better, it is standard compliant C and
>>>>>>>>> C++,
>>>>>>>>> the second version is a gcc extension, which works only when
>>>>>>>>> compiling
>>>>>>>>> C, if I remember correctly.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>>>> former is
>>>>>>>> allowed by the C++ parser only since recently.
>>>>>>>>
>>>>>>>
>>>>>>> Well, on the other hand:
>>>>>>> static const RT_TAKS no_alchemy_task;
>>>>>>>
>>>>>>> Will zero initialized the structure just as well...
>>>>>>>
>>>>>>
>>>>>> In that case you will have the object exist in the .bss.
>>>>>>
>>>>>
>>>>> It turns out that old gcc 4.x releases will create a private bss entry
>>>>> for this symbol in any case, which recent ones won't produce
>>>>> regardless
>>>>> of the optimizing level (unless I messed up with nm, but it does not
>>>>> seem so).
>>>>>
>>>>
>>>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code
>>>> will be
>>>> the same anyway.
>>>>
>>>> BTW, there are way more issues with C++ when enabling standard
>>>> compliance. Not sure where all the errors come from and if they easy to
>>>> fixing. But I think we should try to be as clean as possible in out
>>>> external interfaces.
>>>>
>>>
>>> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
>>> all sorts of pedantic modes. I see the other one following with typeof
>>> constructs, later we will get other changes triggered by other
>>> restrictions on gcc extensions, and this general trend is not
>>> acceptable. The fact that the external API headers still share portions
>>> with the implementation does not help, but this is not a reason for
>>> downgrading the C dialect of the latter with ugly work arounds.
>>>
>>> If you really want to go this way, I suggest that you issue a single,
>>> all-in-one patch making the current code base conforming with the C/C++
>>> standard you aim at, so that we have a general overview of the changes.
>>> With that information, we should be able to address strict standard
>>> conformance better, which may involve addressing the
>>> interface/implementation issue with headers.
>>
>> It's pointless to make the core standard-compliant, C or even C++. But
> 
> This has never been considered for sure.
> 
>> we are exposing an interface that definitely has to be compatible with
>> C++ (most of my patches) as we do not have control over the user's
>> toolchain and language (there would be no good reason to restrict it).
>> And if it is trivial to get the interface even ANSI compliant (last
>> patch) and also recommended by GCC to do so in libraries, what pain does
>> it cause to us to follow this road?
>>
> 
> The pain is that we seem to be adding more and more restrictions to the
> C dialect usable by the implementation, because of that sharing with the
> interface. This is not acceptable.

Were do we restrict us here? Give me one example.

> 
>> Yes, the amount of internals currently exposed via the external headers
>> should be optimized. But I guess this is something to be done as cleanup
>> once the code base, including Mercury, settled a bit more.
>>
> 
> This is a copperplate issue, regardless of whether you stack it over the
> dual or single kernel system, and in this respect, the copperplate API
> is stable (although I really have to document it at some point though).

Well, I can have a look at that patch again and try to get those inline
helpers out of the public. Or are they supposed to be used, directly or
indirectly, by applications?

The no_alchemy_task thing is not a dialect issue, so I think it's clear
now. And the __typeof__ is, IMHO, also clear as gcc clearly recommends
to use the underscore version in public headers. And that's all.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/05/2014 10:06 AM, Jan Kiszka wrote:
> On 2014-02-05 09:58, Philippe Gerum wrote:
>> On 02/05/2014 09:49 AM, Jan Kiszka wrote:
>>> On 2014-02-05 09:33, Philippe Gerum wrote:
>>>> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>>>>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>>>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>>>>> If g++ chokes on the initializer part because it is outdated,
>>>>>>>>>>> then
>>>>>>>>>>> using
>>>>>>>>>>> old-fashioned ones may be an option. Actually, I find macroizing
>>>>>>>>>>> this
>>>>>>>>>>> definition quite bad.
>>>>>>>>>>>
>>>>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>>>>> -    .handle = 0,
>>>>>>>>>>> -    .thread = 0
>>>>>>>>>>> +    handle: 0,
>>>>>>>>>>> +    thread: 0
>>>>>>>>>>>        };
>>>>>>>>>>
>>>>>>>>>> No, the previous version is better, it is standard compliant C and
>>>>>>>>>> C++,
>>>>>>>>>> the second version is a gcc extension, which works only when
>>>>>>>>>> compiling
>>>>>>>>>> C, if I remember correctly.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>>>>> former is
>>>>>>>>> allowed by the C++ parser only since recently.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, on the other hand:
>>>>>>>> static const RT_TAKS no_alchemy_task;
>>>>>>>>
>>>>>>>> Will zero initialized the structure just as well...
>>>>>>>>
>>>>>>>
>>>>>>> In that case you will have the object exist in the .bss.
>>>>>>>
>>>>>>
>>>>>> It turns out that old gcc 4.x releases will create a private bss entry
>>>>>> for this symbol in any case, which recent ones won't produce
>>>>>> regardless
>>>>>> of the optimizing level (unless I messed up with nm, but it does not
>>>>>> seem so).
>>>>>>
>>>>>
>>>>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code
>>>>> will be
>>>>> the same anyway.
>>>>>
>>>>> BTW, there are way more issues with C++ when enabling standard
>>>>> compliance. Not sure where all the errors come from and if they easy to
>>>>> fixing. But I think we should try to be as clean as possible in out
>>>>> external interfaces.
>>>>>
>>>>
>>>> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
>>>> all sorts of pedantic modes. I see the other one following with typeof
>>>> constructs, later we will get other changes triggered by other
>>>> restrictions on gcc extensions, and this general trend is not
>>>> acceptable. The fact that the external API headers still share portions
>>>> with the implementation does not help, but this is not a reason for
>>>> downgrading the C dialect of the latter with ugly work arounds.
>>>>
>>>> If you really want to go this way, I suggest that you issue a single,
>>>> all-in-one patch making the current code base conforming with the C/C++
>>>> standard you aim at, so that we have a general overview of the changes.
>>>> With that information, we should be able to address strict standard
>>>> conformance better, which may involve addressing the
>>>> interface/implementation issue with headers.
>>>
>>> It's pointless to make the core standard-compliant, C or even C++. But
>>
>> This has never been considered for sure.
>>
>>> we are exposing an interface that definitely has to be compatible with
>>> C++ (most of my patches) as we do not have control over the user's
>>> toolchain and language (there would be no good reason to restrict it).
>>> And if it is trivial to get the interface even ANSI compliant (last
>>> patch) and also recommended by GCC to do so in libraries, what pain does
>>> it cause to us to follow this road?
>>>
>>
>> The pain is that we seem to be adding more and more restrictions to the
>> C dialect usable by the implementation, because of that sharing with the
>> interface. This is not acceptable.
>
> Were do we restrict us here? Give me one example.

Forcing cast on assigning generic pointers is a restriction, the same 
way disabling arithmetic on them is yet another artificial restriction 
with absolutely no upside on our side, only obfuscation.

>
>>
>>> Yes, the amount of internals currently exposed via the external headers
>>> should be optimized. But I guess this is something to be done as cleanup
>>> once the code base, including Mercury, settled a bit more.
>>>
>>
>> This is a copperplate issue, regardless of whether you stack it over the
>> dual or single kernel system, and in this respect, the copperplate API
>> is stable (although I really have to document it at some point though).
>
> Well, I can have a look at that patch again and try to get those inline
> helpers out of the public. Or are they supposed to be used, directly or
> indirectly, by applications?

Some of them may be, such as pvmalloc(), which guarantees a rt-capable, 
private memory allocation regardless of the underlying real-time core. 
Others won't, such as all of the threadobj_* routines, which are for 
API/skin designers instead.

This is the reason why I suggest again to have all the required changes 
for building for -ansi/c++11 introduced in place first, without even 
trying to move code around, all in a single patch. With that 
information, we may then define some coding rules for the exposed API 
headers for the future, and possibly rearrange the implementation so 
that it is not exposed uselessly to external interfaces.

>
> The no_alchemy_task thing is not a dialect issue, so I think it's clear
> now.

This issue is only relevant to how smart the compiler you use is with 
respect to optimizing the output, when it sees a statically-scoped 
variable which is explicitly read-only.

  And the __typeof__ is, IMHO, also clear as gcc clearly recommends
> to use the underscore version in public headers. And that's all.
>

I don't have any issue with using the alternative keywords to please 
compilers switched to pedantic mode, just like I'm usually preferring 
__asm__ over asm in code. The fact that I'm arguing about some of the 
proposed changes toward supporting -ansi or -std=<whatever>, does not 
mean that I'm asking for all changes to be dropped mindlessly.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-05 10:36, Philippe Gerum wrote:
> On 02/05/2014 10:06 AM, Jan Kiszka wrote:
>> On 2014-02-05 09:58, Philippe Gerum wrote:
>>> On 02/05/2014 09:49 AM, Jan Kiszka wrote:
>>>> On 2014-02-05 09:33, Philippe Gerum wrote:
>>>>> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>>>>>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>>>>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>>>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>>>>>> If g++ chokes on the initializer part because it is outdated,
>>>>>>>>>>>> then
>>>>>>>>>>>> using
>>>>>>>>>>>> old-fashioned ones may be an option. Actually, I find
>>>>>>>>>>>> macroizing
>>>>>>>>>>>> this
>>>>>>>>>>>> definition quite bad.
>>>>>>>>>>>>
>>>>>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>>>>>> -    .handle = 0,
>>>>>>>>>>>> -    .thread = 0
>>>>>>>>>>>> +    handle: 0,
>>>>>>>>>>>> +    thread: 0
>>>>>>>>>>>>        };
>>>>>>>>>>>
>>>>>>>>>>> No, the previous version is better, it is standard compliant
>>>>>>>>>>> C and
>>>>>>>>>>> C++,
>>>>>>>>>>> the second version is a gcc extension, which works only when
>>>>>>>>>>> compiling
>>>>>>>>>>> C, if I remember correctly.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>>>>>> former is
>>>>>>>>>> allowed by the C++ parser only since recently.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well, on the other hand:
>>>>>>>>> static const RT_TAKS no_alchemy_task;
>>>>>>>>>
>>>>>>>>> Will zero initialized the structure just as well...
>>>>>>>>>
>>>>>>>>
>>>>>>>> In that case you will have the object exist in the .bss.
>>>>>>>>
>>>>>>>
>>>>>>> It turns out that old gcc 4.x releases will create a private bss
>>>>>>> entry
>>>>>>> for this symbol in any case, which recent ones won't produce
>>>>>>> regardless
>>>>>>> of the optimizing level (unless I messed up with nm, but it does not
>>>>>>> seem so).
>>>>>>>
>>>>>>
>>>>>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code
>>>>>> will be
>>>>>> the same anyway.
>>>>>>
>>>>>> BTW, there are way more issues with C++ when enabling standard
>>>>>> compliance. Not sure where all the errors come from and if they
>>>>>> easy to
>>>>>> fixing. But I think we should try to be as clean as possible in out
>>>>>> external interfaces.
>>>>>>
>>>>>
>>>>> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
>>>>> all sorts of pedantic modes. I see the other one following with typeof
>>>>> constructs, later we will get other changes triggered by other
>>>>> restrictions on gcc extensions, and this general trend is not
>>>>> acceptable. The fact that the external API headers still share
>>>>> portions
>>>>> with the implementation does not help, but this is not a reason for
>>>>> downgrading the C dialect of the latter with ugly work arounds.
>>>>>
>>>>> If you really want to go this way, I suggest that you issue a single,
>>>>> all-in-one patch making the current code base conforming with the
>>>>> C/C++
>>>>> standard you aim at, so that we have a general overview of the
>>>>> changes.
>>>>> With that information, we should be able to address strict standard
>>>>> conformance better, which may involve addressing the
>>>>> interface/implementation issue with headers.
>>>>
>>>> It's pointless to make the core standard-compliant, C or even C++. But
>>>
>>> This has never been considered for sure.
>>>
>>>> we are exposing an interface that definitely has to be compatible with
>>>> C++ (most of my patches) as we do not have control over the user's
>>>> toolchain and language (there would be no good reason to restrict it).
>>>> And if it is trivial to get the interface even ANSI compliant (last
>>>> patch) and also recommended by GCC to do so in libraries, what pain
>>>> does
>>>> it cause to us to follow this road?
>>>>
>>>
>>> The pain is that we seem to be adding more and more restrictions to the
>>> C dialect usable by the implementation, because of that sharing with the
>>> interface. This is not acceptable.
>>
>> Were do we restrict us here? Give me one example.
> 
> Forcing cast on assigning generic pointers is a restriction, the same
> way disabling arithmetic on them is yet another artificial restriction
> with absolutely no upside on our side, only obfuscation.

Unfortunately required for ordinary C++ support, not only strict
standard compliance. So it is pointless to moan about it IMHO - unless
we want to drop C++ completely.

> 
>>
>>>
>>>> Yes, the amount of internals currently exposed via the external headers
>>>> should be optimized. But I guess this is something to be done as
>>>> cleanup
>>>> once the code base, including Mercury, settled a bit more.
>>>>
>>>
>>> This is a copperplate issue, regardless of whether you stack it over the
>>> dual or single kernel system, and in this respect, the copperplate API
>>> is stable (although I really have to document it at some point though).
>>
>> Well, I can have a look at that patch again and try to get those inline
>> helpers out of the public. Or are they supposed to be used, directly or
>> indirectly, by applications?
> 
> Some of them may be, such as pvmalloc(), which guarantees a rt-capable,
> private memory allocation regardless of the underlying real-time core.
> Others won't, such as all of the threadobj_* routines, which are for
> API/skin designers instead.
> 
> This is the reason why I suggest again to have all the required changes
> for building for -ansi/c++11 introduced in place first, without even
> trying to move code around, all in a single patch. With that
> information, we may then define some coding rules for the exposed API
> headers for the future, and possibly rearrange the implementation so
> that it is not exposed uselessly to external interfaces.

So you just want me to fold patch 2 and 3 together? I don't fully get it
yet.

> 
>>
>> The no_alchemy_task thing is not a dialect issue, so I think it's clear
>> now.
> 
> This issue is only relevant to how smart the compiler you use is with
> respect to optimizing the output, when it sees a statically-scoped
> variable which is explicitly read-only.

Right, so one of the issue it causes has nothing to do with [strict] C++
compliance.

> 
>  And the __typeof__ is, IMHO, also clear as gcc clearly recommends
>> to use the underscore version in public headers. And that's all.
>>
> 
> I don't have any issue with using the alternative keywords to please
> compilers switched to pedantic mode, just like I'm usually preferring
> __asm__ over asm in code. The fact that I'm arguing about some of the
> proposed changes toward supporting -ansi or -std=<whatever>, does not
> mean that I'm asking for all changes to be dropped mindlessly.

Again, the typeof is for ansi, the rest is for [gcc-]C++.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/05/2014 10:42 AM, Jan Kiszka wrote:
> On 2014-02-05 10:36, Philippe Gerum wrote:
>> On 02/05/2014 10:06 AM, Jan Kiszka wrote:
>>> On 2014-02-05 09:58, Philippe Gerum wrote:
>>>> On 02/05/2014 09:49 AM, Jan Kiszka wrote:
>>>>> On 2014-02-05 09:33, Philippe Gerum wrote:
>>>>>> On 02/04/2014 07:03 PM, Jan Kiszka wrote:
>>>>>>> On 2014-02-04 18:53, Philippe Gerum wrote:
>>>>>>>> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>>>>>>>>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>>>>>>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>>>>>>>>> If g++ chokes on the initializer part because it is outdated,
>>>>>>>>>>>>> then
>>>>>>>>>>>>> using
>>>>>>>>>>>>> old-fashioned ones may be an option. Actually, I find
>>>>>>>>>>>>> macroizing
>>>>>>>>>>>>> this
>>>>>>>>>>>>> definition quite bad.
>>>>>>>>>>>>>
>>>>>>>>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>>>>>>>>> -    .handle = 0,
>>>>>>>>>>>>> -    .thread = 0
>>>>>>>>>>>>> +    handle: 0,
>>>>>>>>>>>>> +    thread: 0
>>>>>>>>>>>>>         };
>>>>>>>>>>>>
>>>>>>>>>>>> No, the previous version is better, it is standard compliant
>>>>>>>>>>>> C and
>>>>>>>>>>>> C++,
>>>>>>>>>>>> the second version is a gcc extension, which works only when
>>>>>>>>>>>> compiling
>>>>>>>>>>>> C, if I remember correctly.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Recent g++ is happy with both (no -std forced though). But the
>>>>>>>>>>> former is
>>>>>>>>>>> allowed by the C++ parser only since recently.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Well, on the other hand:
>>>>>>>>>> static const RT_TAKS no_alchemy_task;
>>>>>>>>>>
>>>>>>>>>> Will zero initialized the structure just as well...
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In that case you will have the object exist in the .bss.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It turns out that old gcc 4.x releases will create a private bss
>>>>>>>> entry
>>>>>>>> for this symbol in any case, which recent ones won't produce
>>>>>>>> regardless
>>>>>>>> of the optimizing level (unless I messed up with nm, but it does not
>>>>>>>> seem so).
>>>>>>>>
>>>>>>>
>>>>>>> Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code
>>>>>>> will be
>>>>>>> the same anyway.
>>>>>>>
>>>>>>> BTW, there are way more issues with C++ when enabling standard
>>>>>>> compliance. Not sure where all the errors come from and if they
>>>>>>> easy to
>>>>>>> fixing. But I think we should try to be as clean as possible in out
>>>>>>> external interfaces.
>>>>>>>
>>>>>>
>>>>>> Mmm, no. I don't want to rush merging all kinds of isolated fixes for
>>>>>> all sorts of pedantic modes. I see the other one following with typeof
>>>>>> constructs, later we will get other changes triggered by other
>>>>>> restrictions on gcc extensions, and this general trend is not
>>>>>> acceptable. The fact that the external API headers still share
>>>>>> portions
>>>>>> with the implementation does not help, but this is not a reason for
>>>>>> downgrading the C dialect of the latter with ugly work arounds.
>>>>>>
>>>>>> If you really want to go this way, I suggest that you issue a single,
>>>>>> all-in-one patch making the current code base conforming with the
>>>>>> C/C++
>>>>>> standard you aim at, so that we have a general overview of the
>>>>>> changes.
>>>>>> With that information, we should be able to address strict standard
>>>>>> conformance better, which may involve addressing the
>>>>>> interface/implementation issue with headers.
>>>>>
>>>>> It's pointless to make the core standard-compliant, C or even C++. But
>>>>
>>>> This has never been considered for sure.
>>>>
>>>>> we are exposing an interface that definitely has to be compatible with
>>>>> C++ (most of my patches) as we do not have control over the user's
>>>>> toolchain and language (there would be no good reason to restrict it).
>>>>> And if it is trivial to get the interface even ANSI compliant (last
>>>>> patch) and also recommended by GCC to do so in libraries, what pain
>>>>> does
>>>>> it cause to us to follow this road?
>>>>>
>>>>
>>>> The pain is that we seem to be adding more and more restrictions to the
>>>> C dialect usable by the implementation, because of that sharing with the
>>>> interface. This is not acceptable.
>>>
>>> Were do we restrict us here? Give me one example.
>>
>> Forcing cast on assigning generic pointers is a restriction, the same
>> way disabling arithmetic on them is yet another artificial restriction
>> with absolutely no upside on our side, only obfuscation.
>
> Unfortunately required for ordinary C++ support, not only strict
> standard compliance. So it is pointless to moan about it IMHO - unless
> we want to drop C++ completely.
>
>>
>>>
>>>>
>>>>> Yes, the amount of internals currently exposed via the external headers
>>>>> should be optimized. But I guess this is something to be done as
>>>>> cleanup
>>>>> once the code base, including Mercury, settled a bit more.
>>>>>
>>>>
>>>> This is a copperplate issue, regardless of whether you stack it over the
>>>> dual or single kernel system, and in this respect, the copperplate API
>>>> is stable (although I really have to document it at some point though).
>>>
>>> Well, I can have a look at that patch again and try to get those inline
>>> helpers out of the public. Or are they supposed to be used, directly or
>>> indirectly, by applications?
>>
>> Some of them may be, such as pvmalloc(), which guarantees a rt-capable,
>> private memory allocation regardless of the underlying real-time core.
>> Others won't, such as all of the threadobj_* routines, which are for
>> API/skin designers instead.
>>
>> This is the reason why I suggest again to have all the required changes
>> for building for -ansi/c++11 introduced in place first, without even
>> trying to move code around, all in a single patch. With that
>> information, we may then define some coding rules for the exposed API
>> headers for the future, and possibly rearrange the implementation so
>> that it is not exposed uselessly to external interfaces.
>
> So you just want me to fold patch 2 and 3 together? I don't fully get it
> yet.

I'm asking for a clarification: do you have more patches following these 
two? I understood from the past conversation that more work was 
required, so I'm assuming you will have. If so, then we may save a lot 
of time by seeing the complete change set that would fit the bill for 
supporting standard C/C++ restrictions, the way your current port work 
seems to require it.

>
>>
>>>
>>> The no_alchemy_task thing is not a dialect issue, so I think it's clear
>>> now.
>>
>> This issue is only relevant to how smart the compiler you use is with
>> respect to optimizing the output, when it sees a statically-scoped
>> variable which is explicitly read-only.
>
> Right, so one of the issue it causes has nothing to do with [strict] C++
> compliance.

Which is the reason why I tend to suspect patches claiming about fixing 
some perceived ugliness, factual information is better. This construct 
is valid, but does not fit well with the gcc release you are aiming at, 
which is another issue. Xenomai 3.x does impose minimum requirements on 
the compiler/toolchain, including sane/working support of builtin sync 
primitives and tls.

In this respect, your patch about no_alchemy_task would have been better 
explained by the goal of not depending on too recent optimizers, which 
does make sense to me. The language is important so that my limited 
mono-neuronal brain can deal with your commit logs.

>
>>
>>   And the __typeof__ is, IMHO, also clear as gcc clearly recommends
>>> to use the underscore version in public headers. And that's all.
>>>
>>
>> I don't have any issue with using the alternative keywords to please
>> compilers switched to pedantic mode, just like I'm usually preferring
>> __asm__ over asm in code. The fact that I'm arguing about some of the
>> proposed changes toward supporting -ansi or -std=<whatever>, does not
>> mean that I'm asking for all changes to be dropped mindlessly.
>
> Again, the typeof is for ansi, the rest is for [gcc-]C++.
>

By pedantic mode, I do mean strict -ansi. So we basically agree. Again.

-- 
Philippe.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-05 11:10, Philippe Gerum wrote:
> On 02/05/2014 10:42 AM, Jan Kiszka wrote:
>> So you just want me to fold patch 2 and 3 together? I don't fully get it
>> yet.
> 
> I'm asking for a clarification: do you have more patches following these
> two? I understood from the past conversation that more work was
> required, so I'm assuming you will have. If so, then we may save a lot
> of time by seeing the complete change set that would fit the bill for
> supporting standard C/C++ restrictions, the way your current port work
> seems to require it.

I'm not aware of further issues after the __typeof__ thing. However, I
will try to run through all public headers in an automated way,
including them in strict modes to check if there is something remaining.
Maybe we can also hook this into our build tests here.

> 
>>
>>>
>>>>
>>>> The no_alchemy_task thing is not a dialect issue, so I think it's clear
>>>> now.
>>>
>>> This issue is only relevant to how smart the compiler you use is with
>>> respect to optimizing the output, when it sees a statically-scoped
>>> variable which is explicitly read-only.
>>
>> Right, so one of the issue it causes has nothing to do with [strict] C++
>> compliance.
> 
> Which is the reason why I tend to suspect patches claiming about fixing
> some perceived ugliness, factual information is better. This construct
> is valid, but does not fit well with the gcc release you are aiming at,
> which is another issue. Xenomai 3.x does impose minimum requirements on
> the compiler/toolchain, including sane/working support of builtin sync
> primitives and tls.
> 
> In this respect, your patch about no_alchemy_task would have been better
> explained by the goal of not depending on too recent optimizers, which
> does make sense to me. The language is important so that my limited
> mono-neuronal brain can deal with your commit logs.

OK, will do /s/ugliness/objective reason for ugliness/.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka]

On 2014-02-05 11:28, Jan Kiszka wrote:
> On 2014-02-05 11:10, Philippe Gerum wrote:
>> On 02/05/2014 10:42 AM, Jan Kiszka wrote:
>>> So you just want me to fold patch 2 and 3 together? I don't fully get it
>>> yet.
>>
>> I'm asking for a clarification: do you have more patches following these
>> two? I understood from the past conversation that more work was
>> required, so I'm assuming you will have. If so, then we may save a lot
>> of time by seeing the complete change set that would fit the bill for
>> supporting standard C/C++ restrictions, the way your current port work
>> seems to require it.
> 
> I'm not aware of further issues after the __typeof__ thing. However, I
> will try to run through all public headers in an automated way,
> including them in strict modes to check if there is something remaining.
> Maybe we can also hook this into our build tests here.

Done this, found 2 more spots regarding typeof, but that's it. What I
tested was this:

#!/bin/bash

XENO_INCLUDE_DIR= \
	`. xeno-config --core >/dev/null; echo $XENO_INCLUDE_DIR`

exclude_patterns="
	\/uapi\/ \
	boilerplate\/private-list.h \
	boilerplate\/shared-list.h"

for f in `find $XENO_INCLUDE_DIR -name *.h`; do
	echo -n "$f - "
	skip=0
	for pattern in $exclude_patterns; do
		if [ "${f/$pattern//}" != "$f" ]; then
			echo "skipped"
			skip=1
			break
		fi
	done
	if [ $skip -ne 0 ]; then
		continue;
	fi
	echo "#include <"${f#include/}">" > .build-test.c
	gcc -Wall -Werror `xeno-config --skin=alchemy --skin=posix \
		--skin=vxworks --skin=psos --cflags` -c .build-test.c \
		-o .build-test.o
	if [ $? != 0 ]; then
		break;
	fi
	echo -n "C "
	g++ -std=c++98 -Wall -Werror `xeno-config --skin=alchemy \
		--skin=posix --skin=vxworks --skin=psos --cflags` \
		-c .build-test.c -o .build-test.o
	if [ $? != 0 ]; then
		break;
	fi
	echo "C++"
	rm -f .build-test.[co]
done

So the patch
http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=884b5d74df015c39961452965e28a8ec69a92a3c
in for-forge now contains everything required to include all headers in
strict standard mode.
http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=a79f18bf7254eb91ad64def9b30d6b4f68e9247b
is required already for permissive GCC C++ mode.

Jan

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[dietmar.schindler]

> Von: Philippe Gerum
> Gesendet: Dienstag, 4. Februar 2014 18:49
>
> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
> > On 02/04/2014 06:39 PM, Philippe Gerum wrote:
> >> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
> >>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
> >>>> If g++ chokes on the initializer part because it is outdated, then
> >>>> using
> >>>> old-fashioned ones may be an option. Actually, I find macroizing this
> >>>> definition quite bad.
> >>>>
> >>>> static const RT_TASK no_alchemy_task = {
> >>>> -    .handle = 0,
> >>>> -    .thread = 0
> >>>> +    handle: 0,
> >>>> +    thread: 0
> >>>>     };
> >>>
> >>> No, the previous version is better, it is standard compliant C and C++,
> >>> the second version is a gcc extension, which works only when compiling
> >>> C, if I remember correctly.
> >>>
> >>
> >> Recent g++ is happy with both (no -std forced though). But the former is
> >> allowed by the C++ parser only since recently.
> >>
> >
> > Well, on the other hand:
> > static const RT_TAKS no_alchemy_task;
> >
> > Will zero initialized the structure just as well...
> >
>
> In that case you will have the object exist in the .bss.

If different compiler versions find fault with different initializer styles and some initializer is wanted in either case due to the .bss issue, then perhaps a not designated initializer would do.

static const RT_TASK no_alchemy_task = { 0, 0 };

--
Best regards,
Dietmar Schindler
________________________________
manroland web systems GmbH -- Management Board: Eckhard Hoerner-Marass (Spokesman), Joern Gossé
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail !
________________________________

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Gilles Chanteperdrix]

On 02/04/2014 06:12 PM, Jan Kiszka wrote:
> On 2014-02-04 17:36, Philippe Gerum wrote:
>> On 02/04/2014 04:18 PM, git repository hosting wrote:
>>> Module: xenomai-jki
>>> Branch: for-forge
>>> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>> URL:
>>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>>
>>>
>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>> Date:   Tue Feb  4 16:12:07 2014 +0100
>>>
>>> alchemy: Replace static variable no_alchemy_task with macro
>>>
>>> The current definition of a static const variable representing an
>>> invalid alchemy task is both C++-incompatible and also ugly as we do not
>>> use them in every module that includes task.h. So replace it with a
>>> macro that builds the required struct on-the-fly.
>>
>> Could you elaborate on the ugly part of things? I don't really get your
>> point.
>
> It is ugly to define potentially unused static variables in a header,
> even more when this header is part of the public interface, pulled in by
> our users with hard to predict compiler configurations. But more
> important is the conflict with C++ (including C++11).

Are you sure you are using a C++ compiler recent enough?

Using g++ 4.7, I do not get any warning compiling the following code:

#include <stdio.h>
#include <stdlib.h>

struct x {
	unsigned a;
	unsigned b;
} y = {
	.a = 42,
	.b = 43,
};

int main(void)
{
	printf("%u\n", y.a);
}

Without even passing a -std option.


-- 
					    Gilles.

Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Philippe Gerum]

On 02/04/2014 06:31 PM, Gilles Chanteperdrix wrote:
> On 02/04/2014 06:12 PM, Jan Kiszka wrote:
>> On 2014-02-04 17:36, Philippe Gerum wrote:
>>> On 02/04/2014 04:18 PM, git repository hosting wrote:
>>>> Module: xenomai-jki
>>>> Branch: for-forge
>>>> Commit: bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>>> URL:
>>>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=bffcc58ed0114985a4d8d8a4cff2adff1b13292d
>>>>
>>>>
>>>>
>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>> Date:   Tue Feb  4 16:12:07 2014 +0100
>>>>
>>>> alchemy: Replace static variable no_alchemy_task with macro
>>>>
>>>> The current definition of a static const variable representing an
>>>> invalid alchemy task is both C++-incompatible and also ugly as we do
>>>> not
>>>> use them in every module that includes task.h. So replace it with a
>>>> macro that builds the required struct on-the-fly.
>>>
>>> Could you elaborate on the ugly part of things? I don't really get your
>>> point.
>>
>> It is ugly to define potentially unused static variables in a header,
>> even more when this header is part of the public interface, pulled in by
>> our users with hard to predict compiler configurations. But more
>> important is the conflict with C++ (including C++11).
>
> Are you sure you are using a C++ compiler recent enough?
>
> Using g++ 4.7, I do not get any warning compiling the following code:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> struct x {
>      unsigned a;
>      unsigned b;
> } y = {
>      .a = 42,
>      .b = 43,
> };
>
> int main(void)
> {
>      printf("%u\n", y.a);
> }
>
> Without even passing a -std option.
>
>

Same here. Old 4.3 codesourcery would break with the initializers though.

-- 
Philippe.