conversion of the __inline__ and inline pragmas to RTEMS_INLINE_ROUTINE?

[Cudmore, Alan P. (GSFC-5820)]

On Nov 9, 2011, at 11:00 AM, Ralf Corsepius wrote:

> On 11/09/2011 04:21 PM, Cudmore, Alan P. (GSFC-5820) wrote:
>> My code needs to have the __inline__ pragma. The inline will not compiler with the switches that I am required to use.
>> Our coding standard dictates:
>>      -Wall -Wstrict-prototypes -pedantic -ansi -Werror
> 
> Well, IMO, these coding standards are pretty questionable for several 
> reasons:
> 
> a) All that -Werror does is to raise arbitrary warnings, which your 
> version of gcc believes are "questionable pieces of code" to errors.
> - This doesn't add any new information to the warnings the other flags 
> already trigger.
> - The gcc raises warnings for contain "false warnings" and "stylistic 
> warning". The more aggressive flags you are using, the more such 
> "neglible warnings" you will see.
> - The warnings gcc raises are gcc-version dependent.
> I.e. even if you manage to get things compiled without any warning with 
> one version of gcc, different versions of GCC will raise different 
> warnings and let your compilation fail due to -Werror.
> 
> b) -ansi will turn off prototypes of functions in newlib, RTEMS 
> currently relies upon (This is the c89/c99 compatibility issue in 
> newlib), I just mentioned in another mail. I.e. you are likely to be 
> facing "implicit decls" due to -ansi, and are not unlikely to be facing 
> miscompilation.
> 
> c) -pedantic (and -Wextra) lets GCC trigger warnings, it itself doesn't 
> consider to be "fail safe" => it will trigger further "false warnings".
> 
> d) -Wstrict-prototypes is good thing and prevents a lot of issues.
> 
> Ralf
> 

Thanks for the information. Our coding standards are due for a review.

A couple of questions:
1. Is it dangerous or not good practice to compile the RTEMS source and the application with different flags?
     ( the flags I listed earlier were for our applications only )
2. Is RTEMS moving toward C99 compliance?

Thanks,
Alan