On Dec 17, 2013, at 6:34 PM, Richard Smith <[email protected]> wrote:
> On Tue, Dec 17, 2013 at 5:47 PM, David Vandevoorde <[email protected]> wrote:
>
> On Dec 17, 2013, at 5:22 PM, John McCall <[email protected]> wrote:
>
>> On Dec 17, 2013, at 12:01 PM, Sean Hunt <[email protected]> wrote:
>>> On Tue, Dec 17, 2013 at 2:57 PM, John McCall <[email protected]> wrote:
>>> On Dec 17, 2013, at 11:12 AM, David Vandevoorde <[email protected]> wrote:
>>> > On Dec 16, 2013, at 8:33 PM, John McCall <[email protected]> wrote:
>>> >> On Dec 16, 2013, at 5:10 PM, Richard Smith <[email protected]>
>>> >> 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.
>
> I find that a little surprising, since GCC does not guarantee this, and it is
> the system compiler on a lot of platforms. (Likewise, Clang does not, and is
> the system compiler on some platforms). There's a GCC bug on this with only
> two duplicates, and no Clang bug has been filed, so I don't get the
> impression that this is a big deal for a lot of people on Linux or Mac.
>
> On the other hand, MSVC guarantees something much stronger: it appears to
> give *all* string literals a mangled name comprising their type, the first
> few (32?) characters of the string, and a checksum of the rest.
Hmm, that’s interesting. I wonder how that interacts with their string-pooling
option (/GF), which is what I was looking at before.
I assume that the mangled name isn’t exported from the DLL, though.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
