[Bug c/52952] Wformat location info is bad (wrong column number)

["dodji at seketeli dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #9 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-05-24 18:38:40 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a Ãcrit:

> So either one keeps track of all source locations of all "interesting"
> characters within strings, which sounds infeasible. Or one needs to
> re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> this possible?

With the current infrastructure, I fear we cannot re-process the format
string *after* the initial pre-processing phase is done, to create new
locations that we'd a in the line maps.

However, briefly looking at the source code, we might be able to pull
this whole shebang off, in a way.

I am thinking that in gcc/c-family/c-format.c:check_format_info_main, we
can arrange for the instance of format_kind_info (that is the result of
parsing the format string) to carry the virtual location  of the
beginning of the format string *and* the offset of the relevant
character we might want to warn about.

Then, later the routines that trigger the warning by analyzing the instance of
format_kind_info could be passed the relevant location for the beginning
of the of the format string as well as the byte offset of the relevant
character I talked about above.  At warning type, it could re-construct
the exact column where of that relevant character, with its byte offset
and the virtual location of the beginning of the format string.

Does that make sense?