On Tue, 2019-04-09 at 10:01 -0400, David Malcolm wrote: > On Tue, 2019-04-09 at 09:21 +0200, Jakub Jelinek wrote: > > Hi! > > > > Several further spots with trailing whitespace, only > > bootstrapped/regtested > > on x86_64-linux and i686-linux (so the ipa-devirt.c change is > > covered), > > the rest is just by eyeballing gcc.pot. > > > > Ok for trunk? > > > > I wonder where and how we could check for this kind of errors, > > unfortunately > > the strings are extracted by xgettext which we can't easily patch > > for > > our > > purposes (say to emit warnings about > > "word" > > "another word" > > or > > "word " > > " another word" > > or for this trailing whitespace (this one could be done even on > > gcc.pot itself > > by looking for ' "\nmsgstr', but unfortunately we have various > > cases > > where > > we intentionally do want those: one category is usually when it > > ends > > with > > ": ", like: > > msgid "invalid 'asm': " > > msgstr "" > > (many cases), but there are even > > "Go ahead? (y or n) " > > msgstr "" > > or > > msgid "The following options are specific to just the language " > > msgstr "" > > "%s\tcompiled by GNU C version %s, " > > msgstr "" > > msgid "vtable for " > > msgstr "" > > msgid "%r%s:%d:%d:%R " > > msgstr "" > > etc., so it is hard to do this programmatically, unless we had some > > white > > list. > > > Thinking aloud, maybe c-format.c could check for some of > these? (provided they're at a suitable callsite). > > We're already statically checking for valid format codes/types for > strings at callsites of decls with ATTRIBUTE_GCC_DIAG; maybe that > test > could also check for things like trailing whitespace within the > string? > > Wouldn't help for the LINK_SPEC things, though.
FWIW, I *think* the substring location stuff retains enough information for such an extension of c-format.c to detect bad concatenation cases like: "word" "another word" > > Dave > > [...snip...]
