Am 21.09.21 um 12:10 schrieb Carlo Arenas: >> - strbuf_addf(&fmt, "%%s%%s%%s-%%0%1$lud.%%0%1$lud-%%s-%%s-%%s", >> - (unsigned long)tmp.len); >> + strbuf_addf(&fmt, "%%s%%s%%s-%%0%lud.%%0%lud-%%s-%%s-%%s", >> + (unsigned long)tmp.len, (unsigned long)tmp.len); > > The C standard version seems simpler to me, so I would say this was a > good outcome overall. I get hypnotized by all those percent signs. %-O >> I may be wrong, but I believe that construct is widely portable, we >> don't use it in the main source, but in the po/ files (so anything that >> uses git + gettext tests for this already): >> >> git grep -P '%\d+\$' -- po I wasn't aware of that extension. Seems useful for translations, when reordering elements is required or convenient to match the sentence structure of a different language. The lack of warnings about the use of that extension in po/ means translated formats are not checked by the compiler at all, right? According to the gettext documentation [2] msgfmt takes care of that when building the translation files, though. > > It is not part of ANY C standard, so it will just print gibberish in > systems that don't carry this extension. > > FWIW is not supported in Windows, which probably explains why they > don't carry the po files. Right, Microsoft doesn't mention it in its printf format documentation [1]. The gettext documentation [3] claims that such platforms get replacement functions automatically via libintl.h. René [1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-160 [2] https://www.gnu.org/software/gettext/manual/gettext.html#c_002dformat-Flag [3| https://www.gnu.org/software/gettext/manual/gettext.html#c_002dformat
