Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need a mangling for string literals in inline variable initializers #78

Open
zygoloid opened this issue Apr 10, 2019 · 1 comment
Open

Comments

@zygoloid
Copy link
Contributor

Consider a case such as

inline const char *str = "foo";

str is required to have a single value across translation units, so the same string literal object must be used as its initializer in all cases. For example:

// TU 1
inline constexpr const char *str = "foo";
const char *x = str;
// TU 2
#include <cassert>
inline constexpr const char *str = "bar";
extern const char *x;
const char *y = str;
int main() { assert(x == y); }

The assertion here is not permitted to fail. Unfortunately, this doesn't only affect string literals appearing in inline variable initializers:

inline constexpr const char *f() { return "foo"; }
inline constexpr const char *x = f(); // must be the same string literal object in all TUs

... and templated variables expose the same issue too:

template<int> constexpr const char *x = "foo"; // x<0> must be the same pointer in all TUs
template<int> struct A {
  static const char *const x;
};
template<int N> constexpr const char *A<N>::x = "foo"; // A<0>::x must be the same pointer in all TUs

I think there are two plausible solutions:

  1. extend the existing _Z <function encoding> Es [ <discriminator> ] mangling to cover this case (note that this means we still need to number string literals within functions and classes, even though we usually don't need the number)

  2. mangle the string literals based only on their contents, for example using whatever mangling scheme we settle on for mangling for non-type template arguments of class type #63 / mangling for string literals #64

I'm inclined to prefer option 2. We should probably also remove the existing mangling for string literals if we take that option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant