Date: Tue, 21 Feb 2023 10:48:56 -0800
On Tuesday, 21 February 2023 09:45:28 PST Jason McKesson via Std-Proposals
wrote:
> While it is true that the standard does not know about DLLs, it also
> doesn't *not* know about them.
>
> That is, it defines the concept of a "program" as a set of translation
> units linked together. Do translation units in a DLL count as part of
> the same "program" as other TUs in other DLLs or exes? One could argue
> that the TUs in a DLL count as part of the same program when it gets
> used. But one could also argue that it isn't.
Indeed. DLLs have DllMain, so one can argue that DLLs are basically lots of
independent programs sharing the address space.
> To me, the issue is that MSVC seems inconsistent on this. When it
> comes to runtime type checking, the answer is "they are the same
> program." You can use RTTI to engage with classes defined by a DLL
> which were not directly exposed to your TU.
s/MSVC/Windows/
The issue has nothing to do with the compiler and instead is imposed by the
OS. Which is why the standard's hands are tied here. When the issues are
contained in the compiler or in the compiler-provided runtime libraries
(vcruntime, msvcr, etc.), it's reasonable to expect that the vendor fix
inconsistencies / non-compliance with the standard. But when it's a deep OS
inconsistency, it's not.
> So it's strange that when it comes to global `new/delete` overloading,
> the answer changes.
>
> Also, what happens on non-Windows platforms if two different SOs
> override the global `new` with different functions?
"It depends."
On Linux, if the two definitions are ELF visibility STV_DEFAULT and there's no
RTLD_LOCAL boundary created by a plugin, then the dynamic linker will choose
one of them at runtime and resolve all references to that one only. Which one
is implementation-defined. Do note that the linker does not guarantee it'll use
the matching operator delete(), though it likely will because the search
orders should be the same.
If the visibility is not STV_DEFAULT, or one of the two was linked with the
linker flag -Bsymbolic or -Bsymbolic-functions, or both of them were loaded by
way of different plugins and both with RTLD_LOCAL, then both functions will be
active at the same time. This is a perfect definition of ODR violation: ill-
formed, no diagnostic emitted at all. And may "just work" too.
On macOS/Darwin, the dynamic linker also has a two-stage search process (it
records which .dylib a symbol was found in). I don't know how operator new
overrides work: they may be the Windows way, they may have an exception and
work the Linux way, or they may be a third way altogether. I haven't bothered
to investigate.
> > If there is a discrepancy, it will be the standard to change to allow for
> > this existing behaviour of 35+ years, which is not going to be changed.
> > No amount of standards-writing will get Microsoft to change such a core
> > level functionality of their OS.
>
> It should also be noted that MSVC already has a few baked-in
> violations of the standard since C++98 that they're just not going to
> fix. For example, `struct` and `class` are supposed to be
> interchangeable by the standard, allowing you to declare a name
> `struct Name;` in one place and define it as `class Name {};`
> elsewhere, with both referring to the same type. But MSVC requires
> that you be consistent. And since this is part of the Windows ABI's
> name mangling, and has been for decades, it's not going anywhere.
Those are MSVC deficiencies, not OS ones. The mangling and C++ ABI is not
Windows's, it's MSVC's. Ditto for the problems of pointer-to-members on
forward-declared classes.
GCC and Clang in MinGW mode are not affected by them because they adopt the
IA-64 C++ ABI, which is free of those issues (it has known, other issues).
It's arguable whether MSVC should just bite the bullet and fix those issues.
They'd been breaking ABI compatibility every single release until MSVC 2015,
so they had lots of opportunities to do so. They chose not to, but could
change their minds again. So a future release of MSVC could have those fixed --
for example, a /Zc:ia64abi option.
A Windows kernel change isn't likely, so it isn't reasonable to expect one.
> The idea that some ink on a page is going to cause the Windows ABI to
> fundamentally change core parts of how stuff works on the platform is
> a fantasy. If some part of the standard is changed in such a way as to
> make implementation of that part highly impractical on their platform,
> they *will not implement it.* Just like GCC took years to implement a
> C++11-compliant `basic_string` because it was an ABI break for their
> old COW-based string implementation.
It probably wouldn't make it into the standard in the first place.
wrote:
> While it is true that the standard does not know about DLLs, it also
> doesn't *not* know about them.
>
> That is, it defines the concept of a "program" as a set of translation
> units linked together. Do translation units in a DLL count as part of
> the same "program" as other TUs in other DLLs or exes? One could argue
> that the TUs in a DLL count as part of the same program when it gets
> used. But one could also argue that it isn't.
Indeed. DLLs have DllMain, so one can argue that DLLs are basically lots of
independent programs sharing the address space.
> To me, the issue is that MSVC seems inconsistent on this. When it
> comes to runtime type checking, the answer is "they are the same
> program." You can use RTTI to engage with classes defined by a DLL
> which were not directly exposed to your TU.
s/MSVC/Windows/
The issue has nothing to do with the compiler and instead is imposed by the
OS. Which is why the standard's hands are tied here. When the issues are
contained in the compiler or in the compiler-provided runtime libraries
(vcruntime, msvcr, etc.), it's reasonable to expect that the vendor fix
inconsistencies / non-compliance with the standard. But when it's a deep OS
inconsistency, it's not.
> So it's strange that when it comes to global `new/delete` overloading,
> the answer changes.
>
> Also, what happens on non-Windows platforms if two different SOs
> override the global `new` with different functions?
"It depends."
On Linux, if the two definitions are ELF visibility STV_DEFAULT and there's no
RTLD_LOCAL boundary created by a plugin, then the dynamic linker will choose
one of them at runtime and resolve all references to that one only. Which one
is implementation-defined. Do note that the linker does not guarantee it'll use
the matching operator delete(), though it likely will because the search
orders should be the same.
If the visibility is not STV_DEFAULT, or one of the two was linked with the
linker flag -Bsymbolic or -Bsymbolic-functions, or both of them were loaded by
way of different plugins and both with RTLD_LOCAL, then both functions will be
active at the same time. This is a perfect definition of ODR violation: ill-
formed, no diagnostic emitted at all. And may "just work" too.
On macOS/Darwin, the dynamic linker also has a two-stage search process (it
records which .dylib a symbol was found in). I don't know how operator new
overrides work: they may be the Windows way, they may have an exception and
work the Linux way, or they may be a third way altogether. I haven't bothered
to investigate.
> > If there is a discrepancy, it will be the standard to change to allow for
> > this existing behaviour of 35+ years, which is not going to be changed.
> > No amount of standards-writing will get Microsoft to change such a core
> > level functionality of their OS.
>
> It should also be noted that MSVC already has a few baked-in
> violations of the standard since C++98 that they're just not going to
> fix. For example, `struct` and `class` are supposed to be
> interchangeable by the standard, allowing you to declare a name
> `struct Name;` in one place and define it as `class Name {};`
> elsewhere, with both referring to the same type. But MSVC requires
> that you be consistent. And since this is part of the Windows ABI's
> name mangling, and has been for decades, it's not going anywhere.
Those are MSVC deficiencies, not OS ones. The mangling and C++ ABI is not
Windows's, it's MSVC's. Ditto for the problems of pointer-to-members on
forward-declared classes.
GCC and Clang in MinGW mode are not affected by them because they adopt the
IA-64 C++ ABI, which is free of those issues (it has known, other issues).
It's arguable whether MSVC should just bite the bullet and fix those issues.
They'd been breaking ABI compatibility every single release until MSVC 2015,
so they had lots of opportunities to do so. They chose not to, but could
change their minds again. So a future release of MSVC could have those fixed --
for example, a /Zc:ia64abi option.
A Windows kernel change isn't likely, so it isn't reasonable to expect one.
> The idea that some ink on a page is going to cause the Windows ABI to
> fundamentally change core parts of how stuff works on the platform is
> a fantasy. If some part of the standard is changed in such a way as to
> make implementation of that part highly impractical on their platform,
> they *will not implement it.* Just like GCC took years to implement a
> C++11-compliant `basic_string` because it was an ABI break for their
> old COW-based string implementation.
It probably wouldn't make it into the standard in the first place.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-02-21 18:48:59