body functions

[Joel Sherrill]

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.
> 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?  It isn't that much code.

> - Move the "body functions" to cpukit/libgnat?
This one implies they are Ada specific and they are not.
> - Eliminate the #defines and supply C-body functions only?
That would be horrible for performance on many of them.
> It's not clear to me which of these ideas are useful or would really
> make sense.
>
>
> Ralf
>
>
> [1] contained in
> cpukit/rtems/src/intrbody.c
> cpukit/rtems/src/rtemsbuildid.c
> cpukit/rtems/src/rtemsbuildname.c
> cpukit/rtems/src/rtemsobjectidapimaximum.c
> cpukit/rtems/src/rtemsobjectidapiminimum.c
> cpukit/rtems/src/rtemsobjectidgetapi.c
> cpukit/rtems/src/rtemsobjectidgetclass.c
> cpukit/rtems/src/rtemsobjectidgetindex.c
> cpukit/rtems/src/rtemsobjectidgetnode.c
> cpukit/score/src/threaddispatch.c
> cpukit/score/src/threadinitialize.c
 From what I remember most of those are dedicated files
just to contain the body of the macro version.  If you
want to provide a dedicated file for each body implementation
of a macro, then that would certainly be consistent.
> used by:
> testsuites/sptests/sp37/init.c
> testsuites/sptests/sp43/init.c
>
Yes.  They have to be tested for coverage.

We have high standards for coverage and those are necessary
to achieve that.
> [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.

> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com         On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985