[cxx-abi-dev] Mangling string constants

Richard Smith richardsmith at googlers.com
Sat Feb 21 00:28:00 UTC 2015


On 20 February 2015 at 15:51, John McCall <rjmccall at apple.com> wrote:

> > On Feb 19, 2015, at 11:44 PM, Dennis Handly <dhandly at cup.hp.com> wrote:
> >> From: David Majnemer <david.majnemer at gmail.com>
> >> It seems that the ABI has no means to mangle the contents of string
> constants.
> >
> > Why is that needed?
> > The current scheme is to just number the constants in order.
> > And that handles both strings and wide strings.
> > And by the ODR rule the inlines must be the same.
>
> I think this is what David means by numbering like a reference temporary.
>
> To the extent that this is needed, I agree with you that that’s the right
> solution: string literals should be mangled in the same sequence as
> reference temporaries.  (Which already applies to more than just reference
> temporaries anyway, since the same concept of lifetime extension applies to
> std::initializer_list temporaries.)
>
> I have some of the same concerns here as I do with guaranteeing the
> uniqueness of string literals within inline functions: I want to make sure
> the language isn’t accidentally promising something that grotesquely
> affects performance far out of proportion to its utility to the
> programmer.  It would be very unfortunate if we, say, introduced thousands
> of new global weak symbols just to unique the strings used by assertions.
> We can take things like this back to the committee if necessary.
>
> But if we can restrict this guarantee to string literals that appear in
> reference-temporary-like positions in constexpr initializers, I think it’s
> reasonable enough.


We can't. Consider:

constexpr const char *f(const char *p) { return p; }
constexpr const char *g() { return "foo"; }
struct X {
  constexpr static const char *p = "foo", // ok
  *q = f("foo"), // not in a "reference-temporary-like" position
  *r = g(); // string literal is not even lexically within the initializer
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150220/2b9bc942/attachment.html>


More information about the cxx-abi-dev mailing list