On Thursday, February 19, 2015 at 11:27:11 PM UTC+1, Tom Tromey wrote: > >>>>> "Axel" writes: > > Axel> I'm talking actual crashes, and I don't know how we would fix the > Axel> text formatter. I'm glancing at > Axel> > http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsTextFormatter.cpp#778, > Axel> and I had no idea how to fix the C++ API there. > > Axel> bug 1133554#c2 is a bug where we got it wrong in en-US, too. Doesn't > Axel> crash, but produces undesirable results. > > Axel> Note, folks using the stringbundle.formatStringFromName just use a > Axel> wstring array. The only code paths affected are those that get the > Axel> string, and explicitly call into nsTextFormatter from c++. > > I think the best answer for C++ is to write a compiler plugin to do > format checking. > > GCC already has code to check that a format string matches the > arguments. However, it can't be applied in several places in the tree > because: > > * Various printf-likes in the tree extend the list of formats. > For example, JS uses %hs to print a char16_t*. > (And nsTextFormatter uses %S for this same thing, oops.) > > * The in-tree printf-likes sometimes use the same format characters as > printf to mean different things. For example, nspr uses %l to mean > 32-bit, whereas printf uses it to mean sizeof(long). > > * Some printf-likes, like nsTextFormatter, use a char16_t* as the format > string. > > There are GCC bugs open about all of these. > > There's also the issue of looking up the format string in a message > catalog. GCC has support for this, too, but I don't know offhand > whether it can handle the approach used here. > > It's possible to fix all these things in the compilers. The advantage > of a plugin is that nobody has to wait for a compiler upgrade to use it > to find the bugs. > > I think it's worth doing. Before I learned about the various problems, > I took a stab at using the GCC format attributes, and amidst all the > nit-picking there are some genuine bugs. > > Tom
We can only do this in the compiler if we actually compiled each localized version by itself. As long as we're using runtime files to switch languages, we can't rely on the compiler to check these things. There are two facets of l10n that we would loose if we went for a compiler-based solution: - language packs, i.e., addons that allow to install just another language. - repacks to create a localized build. This is mostly "good" use of resources, given that a repack takes about a minute or two per language. The other "easy" way to reduce impact here is to reduce the use of nsTextFormatter, or create a replacement that doesn't crash. L20n would be one, or maybe there's C++ template stuff that can "taint" values with their original types. Axel (PS: I wonder why I can't post to .platform via NNTP anymore :-/ ) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
