This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix backwards compatibility problem in libstdc++
- From: Paolo Carlini <pcarlini at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 13 Oct 2006 19:02:52 +0200
- Subject: Re: [PATCH] Fix backwards compatibility problem in libstdc++
- References: <20061013165326.GN20982@devserv.devel.redhat.com>
It seems theSob :(
changes broke libstdc++ backwards compatibility, some GCC 3.4.x compiled
programs and/or libraries misbehave with GCC 4.0.x and later libstdc++.so.6.
The problem is if some 3.4.x program/library has an inlined copy of
_S_construct or _M_clone (that means it initializes _M_length and
_M_refdata's last char, but not _M_refcount) and calls out of line
_S_create (which in GCC 3.4.x used to clear _M_refcount, but after
the above patch it no longer does), then _M_refcount is uninitialized.
When running 3.4.x code against 3.4.x libstdc++ or 4..x code against
4..x libstdc++ there is no problem, in the first case _M_refcount
is initialized in _S_create, in the latter in _S_construct/_M_clone that
Yes, certainly ok for now, we can always try to figure out something a
tad cleaner at a later stage (the comment is very appropriate indeed).
I'm afraid the only safe fix is now to clear _M_refcount in _S_create
in addition to clearing it in its callers (well, it is just one int/long
store, so it shouldn't slow things that much).
Ok for trunk/4.1/4.0?