[cxx-abi-dev] Mangling string constants

Richard Smith richardsmith at googlers.com
Thu Feb 19 23:04:46 UTC 2015


On 19 February 2015 at 14:51, David Majnemer <david.majnemer at gmail.com>
wrote:

> Hi,
>
> It seems that the ABI has no means to mangle the contents of string
> constants.
>
> The cxx-abi-dev archives have a proposal
> http://sourcerytools.com/pipermail/cxx-abi-dev/2012-January/000032.html
> but it seems this was never integrated into the ABI document.  Further, the
> proposal doesn't specify how to mangle UTF-16/UTF-32 string literals.  Such
> a mangling would have to specify the endianness used to encode the code
> points.
>
> At the moment, I am trying to figure out how we should mangle the string
> constant in:
> struct X {
>   static constexpr const char *p = "foo";
> };
>
> We are required to give the storage for the string the same name in all
> translation units in order to adhere to the ODR.
>
> One idea I had was to treat it like a lifetime extended temporary but this
> might break compatibility with existing programs.
>
> Are there any preferences as to what should be done?
>

A related case:

inline constexpr const char *f() { return "foo"; }
struct X {
  static constexpr const char *p = f(), *q = f();
};

We've removed the language rule that required that p == q, but we still
have a constraint that every translation unit sees the same value for p.

I think the simplest way to address this problem and David's original one
is to give a mangling for string literals based on their contents. This
mangling would be optional in all cases *except* where the string literal
object must be the same across translation units, in which case the
mangling must be used and the string literal must be emitted with vague
linkage. I would expect there are few enough such cases that we don't need
to worry about the implied extra symbols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150219/8024b1e3/attachment.html>


More information about the cxx-abi-dev mailing list