This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch / RFC ] Fix libstdc++/36742 on the 4_2-branch
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Paolo Carlini" <paolo dot carlini at oracle dot com>
- Cc: libstdc++ at gcc dot gnu dot org, iant at google dot com
- Date: Mon, 7 Jul 2008 13:02:59 +0200
- Subject: Re: [Patch / RFC ] Fix libstdc++/36742 on the 4_2-branch
- References: <5185654.1215428103884.JavaMail.oracle@acsmt303.oracle.com>
On Mon, Jul 7, 2008 at 12:55 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> apparently, aliasing days...
>
> Anyway, I have a tentative patch for this bug, which affects only 4_2-branch (but, I understand, even after Ian's patches may well be latent on 4_3-branch and mainline).
>
> Our old basic_string uses this _S_empty_rep_storage trick, which is a statically allocated array of size_type, not of plain chars. That, on one side ameliorates the alignment issues, on the other side certainly makes the whole thing weaker wrt aliasing (if I understand correctly). Thus my idea would be changing its type to array of chars while keeping the size_t alignment. Somehow, the patch works, 4_2 is fixed, and passes regtesting (ABI-included of course, mainline too), seems a definite improvement to me (by the way, in mainline, where the alignment attribute is finally fixed vs template, we can generically use __alignof__((size_type)), not size_t).
>
> I'm mostly worried at the moment by ABI stability: _S_empty_rep_storage is *exported* and wheres it's just an array of chars, same size and same alignment of the old one, I fear code linking to the exported symbol can see the difference, somehow. Any help about that?
Can you create an alias from the old symbol? Otherwise this will
likely break code linking to that symbol.
OTOH as 4.2 might not get another release we could decide to ignore
this issue ...
Richard.