Scope encoding of string literals in default arguments questions

[scott douglass]

Hi,

I have some questions about the scope encoding of string literals in inline functions.  Consider,

  bool g(const char*);

  inline const char* f1(const char* p = "world");  // _ZZ2f1Es ?

  inline const char* f1(const char* p) {
    g(p);
    g("hello");  // _ZZ2f1Es_0 ?
    g("world");  // _ZZ2f1Es ?
  }


Do I have the encodings correct?  What happens if another translation unit sees just this:

  bool g(const char*);

  inline const char* f1(const char* p) {
    g(p);
    g("hello");  // _ZZ2f1Es ?
    g("world");  // _ZZ2f1Es_0 ?
  }

Another case to consider, when implementing this, is tgat default arguments can be added after the definition:

  inline const char* f2(const char* p) {
    g(p);
    g("hello");  // _ZZ2f2Es
    g("world");  // _ZZ2f2Es_0
  }

  const char* f2(const char* p = "world");  // _ZZ2f2Es ?

On the other hand perhaps string literals in default arguments should not be considered local to the function being declared at all.  Consider this:

  inline const char* f3(const char* p) {
    g(p);
    g("hello");  // _ZZ2f3Es
    g("world");  // _ZZ2f3Es_0
  }

  inline const char* f4() {
    const char* f3(const char* p = "world");  // _ZZ2f4Es ?
    f3();
    g("world");  // _ZZ2f4Es
  }

  inline const char* f5() {
    const char* f3(const char* p = "hi");  // _ZZ2f5Es ?
    f3();
    g("hi");  // _ZZ2f5Es
  }

It seems that the encodings need to be named after the function the declaration is in not the function being declared.  But then what is the appropriate encoding of string literals in default arguments that aren't function-local?

I'll also suggest some minor clarifications to the wording in 5.1.6:
  "Note that this assumes that the same string literal occurring twice in a given function in fact represents a single entity, i.e. has a unique address."

would be better as
  "Note that this means that the same string literal occurring twice in a given inline function in fact represents a single entity, i.e. has a unique address.  It also means that string literals in inline functions do not "tail-share", i.e. the string literals "abc" and "bc" are completely distinct in inline functions."

And
  "even if subsequent optimization makes some of them unnecessary."

would be better as
  "even if subsequent optimization makes some of them unnecessary or base or member initializer expressions are re-ordered."

By the way, the ABI document's HTML has two occuranes "#scope-encoding" that should be "#mangling-scope".

Thanks.