[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to D. Hugh Redelmeier from comment #6)
> > If you can produce another similar example that works with printf, that would also help.
> 
> I don't think that printf is similar enough.  A strftime format doesn't
> interact with varargs in a complex and problematic way.  A string, on its
> own, is or is not a valid strftime format; a string is only a valid printf
> format when considered with the argument list.
> 
> If an arg is marked as a const char * (i.e. unchanging) and has the strftime
> format attribute, it should be accepted as if it were a literal strftime
> argument.  After all, the necessary checking would have been done at this
> routine's points of call.

Assuming that the wrapper is marked with the correct attribute, GCC would need
to know that this const char* comes from the correct wrapper's argument. I am
not sure this is trivial to know at the point of warning without additional
work/info in the front-end. Some comments above have suggested that this
work/info is done for printf, so the first thing someone looking at this should
do is to understand how printf detects this case, and why the same is not done
for strftime, and then try to share as much code between the two cases as
possible. Perhaps it is a bug, perhaps it was never implemented for strftime.
In any case, one would need to debug GCC using two similar and minimal
testcases to understand what is going on.

See http://gcc.gnu.org/wiki/DebuggingGCC if you want to see how this works. As
an exercise, try to find the point of warning while debugging using your
testcase.

Bugs/features are more likely to be fixed if:

1. There is a minimal testcase that reproduces the problem
2. Someone has debugged GCC and identified the problem
3. Someone has done all the legal prerequisites and posted a patch that fixes
the problem
4. Someone has tested and submitted the patch for review
5. Someone has taken care of the review comments and committed the patch

We are not even in 1 and the real work is 2 and 3.