3.6% of heads up: Please correct your #includes or optflags use

[Jerry James]

On Fri, Mar 21, 2008 at 10:49 AM, I wrote:
>  Here's some information that might help others.  My package jlint is
>  on the list.  It compiles all source files with the standard
>  %optflags, and the compiler issues no warnings about missing function
>  declarations.  Invoking 'nm -CD /usr/bin/jlint" lists __fprintf_chk,
>  __printf_chk, __sprintf_chk ... and sprintf.  Compiling by hand shows
>  that all 4 symbols wind up in the jlint.o object file, even before
>  linking.  Compiling with "gcc -E" showed nothing out of the ordinary;
>  the inline sprintf function that expands to a call to __sprintf_chk is
>  there, all right, and before any invocations of sprintf.  I had to dig
>  through a disassembly of the object file to find the problem.  That
>  was fun.
>
>  So gcc is failing to inline the "always inline" sprintf function in
>  one place, jlint.cpp line 189.  That particular invocation of sprintf
>  looks just like several others, so I don't know why gcc did not inline
>  it.  Using "-Winline" doesn't help, because it doesn't warn about
>  inline functions declared in system headers.  Using "-Wsystem-headers
>  -Winline" also prints no warnings, which I consider a gcc bug.  I
>  tried cranking "-finline-limit" up from the default of 600 all the way
>  to 100000 without convincing gcc to inline that call.
>
>  Bottom line:
>  1) As long as gcc can fail to inline calls, your script is going to
>  emit false positives.
>  2) GCC refuses to report that it failed to inline the functions of interest.

Why are the functions affected by FORTIFY_SOURCE defined as inline
functions instead of preprocessor macros?  In the former case, you can
never be sure that the compiler will inline everywhere.  In the latter
case, you know the replacement will happen.  Is there some technical
reason for using inline functions?
-- 
Jerry James
http://loganjerry.googlepages.com/