On Wed, Jul 12, 2023 at 10:34 AM Ofek Shilon via Std-Proposals <std-proposals@lists.isocpp.org> wrote: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?
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