This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libstdc++/9378: 64-bit g++: construct base:std::moneypunct_byname<char>->memoryfault


Benjamin Kosnik wrote:
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.
I agree (with the name argument). I would go even further and
assert that programs that directly construct any of the _byname
facets have unspecified behavior. The only safe (or portable)
way to use the _byname facets is via a call to use_facet<
xxx_byname>(), and even that only after a corresponding call
to has_facet<xxx_byname>()).

In fact, I would even propose that we remove the _byname ctors,
or better yet, the entire facets from the standard ;-) (only
half joking).

Regards
Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]