On 7 November 2014 18:57, Joseph Myers <jos...@codesourcery.com> wrote: > On Fri, 7 Nov 2014, Manuel López-Ibáñez wrote: > >> This patch allows format warnings to point within the format string >> for simple strings. There are a few limitations: >> >> * It does not handle 'const char *' because the location of the >> initializer is not available. The result is the same before and after >> this patch. >> >> * It does not handle non-concatenated tokens, since the preprocessor >> does not keep their location yet. The result after the patch is that >> we point to some arbitrary place between the first " and the first >> newline. This is slightly worse than the current behavior (which >> points to the first "), but I could not figure out a way to detect >> this case and not generate an offset. It is a matter of implementing >> this idea: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952#c13 as a >> follow-up. The line pointed at is the same before and after the patch, >> only the column number is affected. >> >> * It does not handle macros, but the behavior before and after this >> patch is the same (and there is work-in-progress on this: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952#c33) > > Does it also not handle escape sequences in the strings? You appear to > compute offsets in terms of the number of bytes after the start of the > string, then pass this to functions commented to take an offset in > columns, and escape sequences before the point where the warning is being > given are another case where those would differ.
Ops, no. For trivial escape sequences I could just count +1 when a character that results from an escape sequence is found. But without the original string around, I cannot distinguish between \n and \x012. Maybe I can open the file and re-parse the string to find the right column. Of course, this will not work when reading stdin, but in that case the behavior will be the same as currently. It will also allow me to gracefully degrade in the case of non-concatenated tokens. Do you see any other alternative? > Anyway, the front-end changes are OK with appropriate comments that make > clear what the interface is at each point and where the (missing) > conversion from a byte offset within a string to a column offset in the > source file should take place, though someone else ought to review the > line-map changes. Thanks for the review. I will try first to fix the escape sequences case. Nonetheless, the line-map changes are useful for the other patch (the Fortran parts are approved). There are 3 entries for libcpp in MAINTAINERS: libcpp Per Bothner <p...@bothner.com> libcpp All C and C++ front end maintainers libcpp Tom Tromey <tro...@redhat.com> Neither Per nor Tom are active in GCC anymore. If the FE maintainers do not feel comfortable reviewing line-map changes, could you nominate Dodji as line-map maintainer if he is willing to accept it? I think he is currently the person that understands that code best. Cheers, Manuel.
