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

manu at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Jun 4 11:19:00 GMT 2012


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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu.org

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-06-04 11:18:46 UTC ---
(In reply to comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.

Where is the best place to store this hash table? And you say the C/C++ FEs,
but it seems to me this would need to be done in libcpp, no?

> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
> and didn't need to be translated.  So, printf ("%.*d"); (the common case)
> wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would
> need that.  For "trivial" string literals you'd just shift the locus by the
> offset, for non-trivial look up the tokens and process them again, looking at
> where the corresponding byte would appear to come from.

What do you mean by "process them again"? Once we have a mapping of location_t
to individual token, the only thing to be done is look inside the string for
the relevant character, no?

Well, this seems to require several big parts:

First, handle locations + offsets in diagnostics. Perhaps we need new
warning_at_offset(location, offset, ...) functions? Or should we encode the
offset in location_t somehow? If an offset parameter is passed explicitly, the
diagnostics code would require a lot of changes to pass the offset around. Not
sure what is the best way to implement this and avoid massive changes.

Second, building the hash table discussed above. Where should it be built?
Where should it be stored? 

Third, location+offset to expanded_location code. This is the part that will
use the above hash table and reprocess the tokens. Exactly how it will work is
not entirely clear to me.

Fourth, use the new infrastructure in Wformat warnings and other places that
inspect strings. Perhaps the offset could also be re-used to implement ranges,
but the diagnostics code would need to handle them differently when used for
ranges and when used to specify a location within a string.

I added Tom Tromey to the CC, perhaps he has some ideas about how to implement
this.



More information about the Gcc-bugs mailing list