This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Martin Sebor <sebor at roguewave dot com>
- Cc: bkoz at gcc dot gnu dot org, axiong at ca dot ibm dot com, gcc-bugs at gcc dot gnu dot org,gcc-prs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Wed, 29 Jan 2003 20:34:37 -0600
- Subject: Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memory fault
- References: <20030129210511.4436.qmail@sources.redhat.com><3E38467A.4050409@roguewave.com>
On Wed, 29 Jan 2003 14:24:10 -0700
Martin Sebor <sebor@roguewave.com> wrote:
>
>FWIW, I don't think the requirements on the ctors of class
>locale are relevant in this case. The problem is, IMO, that
>there are no requirements at all on the ctors of the byname
>facets, so pretty much anything goes. I.e., abort is just
>as legal as successful construction.
Hmm. I wasn't paying attention, and didn't realize these were _byname facets.
It doesn't really matter though, because....
22.1.1.1.2 - Class locale::facet [lib.locale.facet]
-4- For some standard facets a standard ``..._byname'' class, derived
from it, implements the virtual function semantics equivalent to that
facet of the locale constructed by locale(const char*) with the same
name.
So, with this equivalence argument, I think the original point still
holds: these name strings are implementation-defined, and people should
not assume that any arbitray string will in fact, lead to a constructed
locale object.
-benjamin