>>>>> "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ  
>>>>> <axel-4ejtqonfjqfbdgjk7y7...@public.gmane.org> 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


_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to