On 3/25/2022 9:51 AM, Dan Cross wrote:
> In article <623dc61c$0$702$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/25/2022 9:16 AM, Dan Cross wrote:
>> [snip]
>>> Of course, all of this works because the name mangling algorithm
>>> is well-specified.
>>
>> If I read that code correctly then it works because the
>> std::arch::asm ... mangled = sym mangled knows what to do.
>>
>> Which is not general language interop.
>
> It "knows what to do" because the name mangling algorithm is
> well-specified by a generic ABI, which is the point:
>
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
>
> Rust provides a convenient mechanism to make this trivial.

Most mangling schemes are documented.

But they are not easily human readable, not compatible with
each other and tend to not be stable over time.

Which is why disabling it is a good thing for language
interop.

Arne

In article <623dd2b3$0$700$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 3/25/2022 9:51 AM, Dan Cross wrote:
>> In article <623dc61c$0$702$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 3/25/2022 9:16 AM, Dan Cross wrote:
>>> [snip]
>>>> Of course, all of this works because the name mangling algorithm
>>>> is well-specified.
>>>
>>> If I read that code correctly then it works because the
>>> std::arch::asm ... mangled = sym mangled knows what to do.
>>>
>>> Which is not general language interop.
>>
>> It "knows what to do" because the name mangling algorithm is
>> well-specified by a generic ABI, which is the point:
>>
>> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
>>
>> Rust provides a convenient mechanism to make this trivial.
>
>Most mangling schemes are documented.

Yup.

>But they are not easily human readable,

That's true, though over time you do sort of pick it
up; kinda like Morse code or something.

>not compatible with
>each other and tend to not be stable over time.

That is NOT true. There's pretty much one that every has
standardized on now, and it is well-specified. It "changes over
time" in the same way that any ABI changes over time: new things
are added as languages etc evolve, but the baseline behavior is
durable.

>Which is why disabling it is a good thing for language
>interop.

We're now at the point of arguing semantics. I gave an example
where one does not _need_ to disable it; that's all. Strictly
speaking, it is not necessary to disable mangling for interop;
whether one wants to for other reasons (readability) or
considers it a good idea in general is orthogonal.

- Dan C.

On 3/25/2022 10:52 AM, Dan Cross wrote:
> In article <623dd2b3$0$700$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/25/2022 9:51 AM, Dan Cross wrote:
>>> In article <623dc61c$0$702$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 3/25/2022 9:16 AM, Dan Cross wrote:
>>>> [snip]
>>>>> Of course, all of this works because the name mangling algorithm
>>>>> is well-specified.
>>>>
>>>> If I read that code correctly then it works because the
>>>> std::arch::asm ... mangled = sym mangled knows what to do.
>>>>
>>>> Which is not general language interop.
>>>
>>> It "knows what to do" because the name mangling algorithm is
>>> well-specified by a generic ABI, which is the point:
>>>
>>> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
>>>
>>> Rust provides a convenient mechanism to make this trivial.
>>
>> Most mangling schemes are documented.
>
> Yup.
>
>> But they are not easily human readable,
>
> That's true, though over time you do sort of pick it
> up; kinda like Morse code or something.
>
>> not compatible with
>> each other and tend to not be stable over time.
>
> That is NOT true. There's pretty much one that every has
> standardized on now, and it is well-specified. It "changes over
> time" in the same way that any ABI changes over time: new things
> are added as languages etc evolve, but the baseline behavior is
> durable.

I thought Rust RFC 2603 changed Rust name mangling??

>> Which is why disabling it is a good thing for language
>> interop.
>
> We're now at the point of arguing semantics. I gave an example
> where one does not _need_ to disable it; that's all.

But the example was not really language interop as the Rust
compiler did the name mangling for the inline assembler.

> Strictly
> speaking, it is not necessary to disable mangling for interop;

True.

One can always find the mangled name either by applying documentation or
by looking at generated code. But that is not good way to code.

> whether one wants to for other reasons (readability) or
> considers it a good idea in general is orthogonal.

But really the interesting/relevant part.

Lots of things are possible. You don't need a compiler
to create a program. It is potentially possible to type
in an EXE file in a hex editor. But nobody would do that.

I hope nobody expose mangled names for external
calling either.

Arne

On 3/25/2022 11:28 AM, Arne Vajhøj wrote:
> On 3/25/2022 10:52 AM, Dan Cross wrote:
>> In article <623dd2b3$0$700$14726298@news.sunsite.dk>,
>>> not compatible with
>>> each other and tend to not be stable over time.
>>
>> That is NOT true.  There's pretty much one that every has
>> standardized on now, and it is well-specified.  It "changes over
>> time" in the same way that any ABI changes over time: new things
>> are added as languages etc evolve, but the baseline behavior is
>> durable.
>
> I thought Rust RFC 2603 changed Rust name mangling??

And to quote Microsoft documentation for MSVC++:

<quote>
The decorated naming conventions have changed in various versions of
Visual Studio, and can also be different on different target
architectures. To link correctly with source files created by using
Visual Studio, C and C++ DLLs and libraries should be compiled by using
the same compiler toolset, flags, and target architecture.

Note

Libraries built with Visual Studio 2015 can be consumed by applications
built with Visual Studio 2017 or Visual Studio 2019.
</quote>

Arne

In article <623ddf93$0$697$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 3/25/2022 10:52 AM, Dan Cross wrote:
>> That is NOT true. There's pretty much one that every has
>> standardized on now, and it is well-specified. It "changes over
>> time" in the same way that any ABI changes over time: new things
>> are added as languages etc evolve, but the baseline behavior is
>> durable.
>
>I thought Rust RFC 2603 changed Rust name mangling??

RFC 2603 hasn't been approved; the tracking issue is very much
still open.

>>> Which is why disabling it is a good thing for language
>>> interop.
>>
>> We're now at the point of arguing semantics. I gave an example
>> where one does not _need_ to disable it; that's all.
>
>But the example was not really language interop as the Rust
>compiler did the name mangling for the inline assembler.

Semantics.

>> Strictly
>> speaking, it is not necessary to disable mangling for interop;
>
>True.
>
>One can always find the mangled name either by applying documentation or
>by looking at generated code. But that is not good way to code.

That's a value judgement.

>> whether one wants to for other reasons (readability) or
>> considers it a good idea in general is orthogonal.
>
>But really the interesting/relevant part.
>
>Lots of things are possible. You don't need a compiler
>to create a program. It is potentially possible to type
>in an EXE file in a hex editor. But nobody would do that.

That's a separate discussion. If you want to have that
discussion, that's fine; I agree with you. But that's not
the discussion we were having (which was about possiblity,
or at least that's what I thought).

>I hope nobody expose mangled names for external
>calling either.

Separate compilation is a good thing, even within a single
language.

- Dan C.