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.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
