This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: warning for -Wformat and non-literal-string format


 > From: Ken Raeburn <raeburn@raeburn.org>
 >  
 > It's also got code where a function needs to be passed a pointer to a
 > function that takes a printf-style format string and va_list (which
 > get passed in from elsewhere -- this is a callback function for error
 > reporting).  I'd like to do more checking of that function pointer and
 > the called function eventually, but that gets really hairy.

Right.  IIRC, gcc doesn't currently accept format specifiers on
function pointers, only on function prototypes.  I looked into
allowing it and got it to work somewhat, but when I tried to get all
cases where a function pointer could appear, like in an array, struct,
etc, it got hairy.



 > > Another approach which only takes into account the called function,
 > > would be to notice what distinguishes the false positive functions is
 > > that the format of the called function is always set to (N, 0) where N
 > > is the format field, and 0 is the "first-arg" field.  I think it is
 > > almost always the case that functions taking va_list (as opposed to
 > > ...) are passed a non-literal format string, and all of these are set
 > > with a "first-arg" parameter of zero.
 >  
 > So if vprintf is a small inline function that calls vfscanf with
 > stdin, it'll be permitted without complaint, since vfscanf has a
 > first-arg of 0?

Well vprintf calling vfscanf is a blatant bug but only because the
standard already defines its behavior.  Is it strictly illegal for a
*user-defined* printf-style function to call a scanf-style one?

Also, your suggestion goes beyond the original purpose of your format
patch which was to detect a non-literal format string.  You are
justifying your solution to the false positives problem by saying it
detects other (IMHO) unrelated non-problems.


 >   I was thinking of adding checks that the caller and
 > callee put the same interpretation (printf vs scanf) on the format
 > string.
 > Ken

Another issue with your approach occurs to me.  What if you want to
define printf-style functions with % specifier extensions.  Because of
these extensions, you cannot declare that the containing function has
any format specifier at all.  But when parsing the individual
specifiers, you may want to pass printf-style ones to vfprintf which
may trigger a false positive.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]