ralf.corsepius at rtems.org
Fri Dec 9 04:44:00 UTC 2011
On 12/08/2011 11:05 PM, Joel Sherrill wrote:
> On 12/08/2011 11:25 AM, Ralf Corsepius wrote:
>> RTEMS contains a set of functions which are implemented as both #defines
>> and as normal functions (aka. body functions).
>> 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.
>> 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
> 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.
More information about the devel