body functions

[Ralf Corsepius]

On 12/08/2011 11:05 PM, Joel Sherrill wrote:
> On 12/08/2011 11:25 AM, Ralf Corsepius wrote:
>> Hi,
>>
>> 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?
> Any language not C-derived (e.g. other than C/C++)
> would have to use the bodies since they can't use the
> macros. I am working slowly on Objective-C and I assume
> that would be able to use the inline versions.
>
> At the moment non-C languages include Ada, Go, GCJ,
> FORTRAN, as well as any assembly language.
>
> It is good form to have bodies of methods in an API that are
> implemented as macros because the macros only work in
> C (or C-related) languages. Providing real bodies gives you
> something to write bindings to.
Right ... conversely: #defines introduce non-portability.

If "other language support" is a desired feature, you can not avoid to 
"not using #defines".

>> 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].
>>
>>
>> I am not sure what do ... crude, uncooked ideas would be:
>>
>> - Split these functions out into a separate library?
> Are these causing that many issues?
1 per file.

> It isn't that much code.

The current implementation is unsafe. E.g. the compiler in many cases 
will not be able to provide "function-argument " type-checking inside of 
these body-functions and in calls to these body-functions, because you 
can not provide prototypes for these body-functions.

[No this threat is not artificial. Check my this week's commits and 
you'll find several such cases, also in RTEMS core routines.]

>> - Move the "body functions" to cpukit/libgnat?
> This one implies they are Ada specific and they are not.
Unless we have another language, they de-facto are Ada specific.

Of course, one could generalize and put these functions into an entirely 
independent and separate library, C-RTEMS would not use.

>> - Eliminate the #defines and supply C-body functions only?
> That would be horrible for performance on many of them.
As I said in my other mail, doubts on the generality of this claim are 
justified.

> We have high standards for coverage and those are necessary
> to achieve that.
Well, 5000 warnings with several really serious ones amongst them speak 
a clear language and seriously question RTEMS's QA efforts so far.

Ralf