From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <52F1FEFC.9070708@siemens.com> Date: Wed, 05 Feb 2014 10:06:04 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <52F1172B.2080500@xenomai.org> <52F11F94.9000309@siemens.com> <52F1231A.7080603@xenomai.org> <52F12442.3040301@xenomai.org> <52F125E8.6020200@xenomai.org> <52F12700.3020400@xenomai.org> <52F12800.1030500@xenomai.org> <52F12937.3050105@xenomai.org> <52F12B7A.4060408@siemens.com> <52F1F749.2030501@xenomai.org> <52F1FB24.4090603@siemens.com> <52F1FD3B.1070304@xenomai.org> In-Reply-To: <52F1FD3B.1070304@xenomai.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum , Gilles Chanteperdrix Cc: xenomai@xenomai.org 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