chrisj at rtems.org
Thu Dec 8 21:24:50 UTC 2011
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).
> 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.
Are the warnings just about these files or other interactions else where ?
> 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 ?
> - Eliminate the #defines and supply C-body functions only?
This would effect performance.
- 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.
> 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 ? Would the warning move with the
code to the library ?
>  contained in
> used by:
>  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.
More information about the devel