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

[John McCall]

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.

I mean, in practice this is going to work just fine in simple cases, because implementations do do some uniquing of string literals, within limits.  But to really make a *guarantee* here, you’re talking about taking a ubiquitously-used language feature and layering a ton of hidden and difficult-to-avoid costs onto it, and for what?  To make the semantics slightly prettier in a way that doesn’t really help anybody?

It is extremely difficult to prove that a program does not rely on the address of a string literal, because the dominant use of string literals is to pass them off to a function, usually one that’s implemented in an external library.

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