body functions

[Ralf Corsepius]

On 12/08/2011 10:24 PM, Chris Johns wrote:
> On 9/12/11 4:25 AM, Ralf Corsepius wrote:
>>
>> RTEMS contains a set of functions which are implemented as both #defines
>> and as normal functions (aka. body functions)[1].
>>
>> This raises a couple implementation problems in RTEMS esp, wrt.
>> using the compiler to enforce stricter coding standards.
>>
>> As things currently appear to me, the only usage of these "body
>> functions" is supporting GNAT/Ada, while no pure C application nor RTEMS
>> itself uses them - Is this understanding correct?
>
> I am not 100% certain and I agree it seems to be a compiler trick to
> make them work. My understanding is given no references are made these
> functions are never linked by a C program.
>
>>
>> Fact seems to be something should be done to get them "out of way" of
>> the C-part of RTEMS to simplify improving the coding quality of RTEMS[2].
>>
>
> Are the warnings just about these files or other interactions else where ?

The problem is the way they currently are implemented, which currently 
condenses to this:


public.h:
#define foo(arg1, arg2) foomacro


implementation.c:

#include <public.h>
#undef foo

arg0_t foo( arg1_t arg1, arg2_t arg2)
{
   [foobody]
}

=> Will raise a missing-prototype "foo" warning.


body-usecase.c:
#include <public.h>
#undef foo
...
  foo(1,2)
...
=> Will raise a missing-prototype "foo" warning.
=> Disables the compiler's argument checking
  == unsafe code (e.g. arg type mismatches will not be diagnosed)


macro-usecase.c:
#include <public.h>
...
  foo(1,2)
...
=> Will raise a missing-prototype "foo" warning.
=> Disables the compiler's argument checking
  == unsafe code (e.g. arg type mismatches will not be diagnosed)


>> I am not sure what do ... crude, uncooked ideas would be:
>>
>> - Split these functions out into a separate library?
>> - Move the "body functions" to cpukit/libgnat?
>
> Would this also be an issue for other languages ?

Joel says so and I am inclined to agree, because many "non-c" languages 
can't cope with #defines.

However, I am not sure why this issue should be limited to only these 
ca. 10 macros and would not affect the way higher number of "other 
macros" in RTEMS.

>> - Eliminate the #defines and supply C-body functions only?
>
> This would effect performance.

Well, I'd expect this claim to apply to some of these functions, but not 
to all.

> - Rename the macro in the specific file and use it wrapped in the
> function version. This way it avoids any skew type issues if
> the implementation changes.
Yep, that could work.

On the implementation side, the key to resolving this issue to me seems 
to be "removing the #undefs" and to use strictly separated symbols.

>> It's not clear to me which of these ideas are useful or would really
>> make sense.
>>
>
> How does moving it to a library help ?
It would be a completely separate 2nd implementation, in parallel to the 
original RTEMS-c-libraries.

In case of Gnat/Ada (And libgnat), this would defacto entirely remove 
the "body functions" from c-RTEMS and make these a Gnat/Ada 
implementation detail.

Problem would be keeping the "2nd implementation" in sync with the 
primary implementation, but it at least would keep the primary 
implementation "clean".

> Would the warning move with the
> code to the library ?
... Depends on how this would be implemented,

>> [2] This weeks's PR and patch flood has its origin in me compiling RTEMS
>> with very aggressive GCC-warning flags.
>>
>> Initial result: >5000 warnings per BSP, with several quite serious ones
>> amongst them.
>
> Ouch.
Yeah, I had expected to be flooded with GCC warnings, but the amount of 
warnings GCC confronted me with, was beyond expectaction - I can't deny 
to be shocked and can't avoid to find this embarrassing.

#1 mistake of serious bugs seems to be not having enforced strict 
prototyping (combined with having banned local redeclarations) and 
excessive use of defines.

I plan to make some of the these flags I am currently experimenting 
with, default in CVS-HEAD, after having moved the biggest road-blocks 
out of the way (The body functions are one of these).

Ralf