This is a statement one meets in many variations, when trying to understand C++'s stance on many real world problems. I imagine I'm not the only one who is deeply uncomfortable with this answer. Even the meaning of this statement is far from obvious: does it mean that code that is linked to a shlib is not susceptible to the standard restrictions? Perhaps programs that link against shared libraries are undefined behavior?
It simply means that shared libraries are outside the scope of the C++ Standard, which is (rightly?) concerned with C++, not with the details of how a particular implementation might implement it.
Similarly, x86-64 instruction encoding is outside the scope of the C++ Standard. Does that mean a program that uses x86-64 instructions is not covered by the Standard? Of course not. It just means that that's a low-level concern (relative to the semantics of C++), and it's up to the platform to make a conforming C++ implementation on top of that stuff.
So I'll disagree with your (1) but agree with your (2a,2b).
> (1) First, a few general descriptive sections should be reviewed and mostly rephrased, probably introducing a concept like 'linkage-unit':
Maybe you just need to be more specific here, but I think you're probably wrong. I don't see why a notion of "linkage-unit" would be useful. Again compare to instruction encoding: we could introduce a standard notion of "encoded-instruction-form," but it wouldn't buy us anything relevant to C++. It's not useful.
(2) More importantly, I'm aware of 2 clauses that the clash with the Windows PE model:
(a) [expr.eq]
http://eel.is/c++draft/expr.eq#3.2, has this to say about comparison of function-pointers: "... if the pointers ... both point to the same function ... they compare equal."
This is not so simple if the function in question is implemented in a shared library: an actual `call` is made to the current binary's PLT (in ELF systems) or IAT (in PE systems), so the direct call address is different across binaries.
IIUC, you're saying that an existing major implementation (MSVC on Windows, and perhaps clang-cl on Windows also) is non-conforming to the letter of the Standard.
This is worthy of a bug report (if easily fixed), or a paper (if not, and I think you're saying not).
Your paper's goal will be to change the wording of [expr.eq] to bring the wording into line with the Windows reality. But, at the same time, your proposed wording ("equality of function pointers is implementation-defined") is simply too broad. We want to be able to rely on pointer equality to Do The Right Thing in C++ programs, don't we?
So your paper should explore
- heroic ways to make MSVC conform to the existing wording
- ways to segregate functions at compile time into "those whose addresses definitely compare equal" and "those whose comparisons are implementation-defined"; this might relate to your (1) above, or it might not
- ways to query at compile time whether we're on a weird platform or not, e.g. `#if __FUNCTION_POINTERS_MIGHT_SPURIOUSLY_COMPARE_UNEQUAL`
- alternatively, what goes wrong with the status quo if we just say "okay, MSVC isn't conforming in this regard" and move on?
"The program's definitions are used instead of the default versions supplied by the implementation." [...]
This doesn't happen in PE DLLs, where the .idata section explicitly says from which DLL to import each function. So for example `new` will by default be imported from the Windows VC-Runtime Dlls, can also be resolved from a static library linked to the DLL - but *NOT* from the main executable.
Same here: This sounds like MSVC is non-conforming. If it's easy to fix, this should be a bug report; if it's hard to fix, perhaps the wording should be changed so that MSVC can be conforming; and the paper should explore different avenues to get there. (And, alternatively, explain whether it's really even a problem if we just say MSVC is non-conforming in this area.)
It would of course be good for the paper's author to talk to some MSVC people. I'm sure these issues (and others) are already known to MSVC, and you can find out whether MSVC cares about them and whether anyone complains about them (via bug reports and forums) in practice.
HTH,
Arthur