This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Fix the narrow/widen problem in money_get::do_get
Martin Sebor wrote:
This was actually discussed in the connext of num_get but it
stands to reason that implementations that call narrow() there
will also call narrow() from money_get. I surveyed about 6
implementations myself (3 versions of ours, STLport, and a couple
of Dinkumware's), and Howard Hinnant chimed in saying that
Metrowerks also calls narrow(). So yes, I am saying that all
these implementations ignore the requirement to widen(). Ours
does so deliberately in order to allow the facets to be
instantiated on user-defined charT's. Plus, our narrow() is
quite efficient in the common case (char, and wchar_t values
between 0 and 256), so we're not concerned about the potential
performance issue Nathan was referring to in his post (calling
do_narrow() for each character).
Both our narrow and our widen are quite efficient in the common
case, that's not the main point, for the simple reason that we cache
those widenings for use in XXX_get facets.
Wait a minute: if I understand well what you saying about the
"missing traits", the same issue would affect num_get and 22.2.2.1.2, p8
and our reading of it, because of course for num_get::do_get we
are following the very same approach, using traits::find and
widening in advance. Clearly strictly following the standard.
Yes, both money_get and num_get are affected.
Therefore gcc3.2 was already affected.
Btw., here's the issue on the "traits problem" in num_get that
I mentioned earlier:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#427
Note that I disagree with text in the note added in Kona,
specifically that
"changing numeric facets to use narrowing instead of widening:
it wouldn't fix the general problem, it would be a drastic
reversal of a deliberate change, and it would probably have
unfortunate performance implications.)"
That PR is in the Open status and the only official position so far, that
which you are mentioning, is **clearly** against your point of view.
Paolo.