[cxx-abi-dev] Mangling of string literals versus variadic templates

[John McCall]

On Dec 17, 2013, at 5:47 PM, David Vandevoorde <daveed at edg.com> wrote:
> On Dec 17, 2013, at 5:22 PM, John McCall <rjmccall at apple.com> wrote:
>> On Dec 17, 2013, at 12:01 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote:
>>> On Tue, Dec 17, 2013 at 2:57 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Dec 17, 2013, at 11:12 AM, David Vandevoorde <daveed at edg.com> wrote:
>>> > On Dec 16, 2013, at 8:33 PM, John McCall <rjmccall at apple.com> wrote:
>>> >> On Dec 16, 2013, at 5:10 PM, Richard Smith <richardsmith at google.com> wrote:
>>> >>> Consider:
>>> >>
>>> >> Remind me why it’s impossible to go back to the committee and repeatedly weaken any remaining guarantees about string literal addresses until none of this is important?
>>> >
>>> > I don't know if it's impossible or not, but I suspect it would be controversial.  (I, at least, would be opposed.)
>>> 
>>> Really?  You feel that having really strong guarantees about the address of a string literal is the right thing to do?  Like, it’s worth significantly increasing build times, code size, and launch times over?
>>> 
>>> John.
>>> 
>>> I don't see a situation where baz() below returns false really being defensible:
>> 
>> Why?  Who cares?  Why is “don’t rely on string literal addresses being consistent” actually an unreasonable piece of advice?  Because I’m pretty sure that’s the advice that everybody’s been rolling with for over thirty years now.
> 
> 
> We put in the C++ rules about 20 years ago because people wanted to have
> 
> 	inline char const* name() { return "SomeName"; }
> 
> return the name pointer value in every TU (I think that's reasonable). There is certainly still plenty of code relying on that.

In a world with pervasive dynamic linking, this is certainly not reasonable as the default language behavior; it simply promises *far* too much.  We shouldn’t have to emit thousands of new symbols that require dynamic coalescing just because a few templates contain some assertions.

(While some strings can be shared between template instantiations, assertions usually use macros like __PRETTY_FUNCTION__ that make the message non-uniquable.)

I am not sure how much code there could possibly be relying on this when only one compiler does what would really be required.  From what I can find in their documentation, Visual Studio apparently does not even pool strings across translation units by default.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20131217/d045bc68/attachment.html>