On Tue, Oct 12, 2010 at 12:37 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Erik Faye-Lund wrote: > >> The string gets inlined into itself (with a limit of 100 expansions) >> leading to string like "foo %1 bar" becoming "foo foo foo ... foo %1 >> bar bar bar ... bar". With our expansion, it becomes "foo % 1 bar" >> instead. > > Ah, ok. Sounds like there is no need to worry about requests for "%%1" > etc. Thanks for explaining. > Actually, %%1 is a bit of a tricky one. It seems that %%1 is used to escape %1 on Windows 7, but not on earlier Windows version. I did test this on Vista an XP earlier, but I'll re-test again later and report back, in case my earlier tests were flawed. Can %%1 occur in an IPv6 address at all? If not, I'm tempted to not handle it (unless it turns out I was wrong about %%1-escaping on Vista and XP). > Maybe the symptoms and cases not covered (%2, %%1) would be worth > mentioning in the log message? > Sorry for the late reply. I'm sure it could be added, I'm just a bit worried about making the whole commit message too intimidating. Something like this, perhaps? ---8<--- Strings containing "%1" gets expanded into themselves by ReportEvent, so let's expand "%1" to "% 1" before reporting, because such string can occur in IPv6-addresses. "%2" and above does not appear to be a problem, probably because ReportEvent checks the number against the wNumStrings parameter first. "%%1" is still a problem, but we don't have a code-path producing such strings. ---8<--- This is (of course), assuming my current findings are correct. The lack of documentation on the subject is really annoying. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html