On Mon, Jul 17, 2023 at 4:57 AM Ofek Shilon <ofekshilon@gmail.com> wrote:
On Wed, 12 Jul 2023 at 17:56, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
[...]
(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. [...]

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.)

Not sure what calls for explanation here. Is "just saying that MSVC is non-conforming" a viable option?

I suppose you mean this as a rhetorical question, and you mean is that a viable option for the Committee. I would say yes. There are plenty of places where WG21 has repeatedly punted on widespread non-conformingness, often involving MSVC, e.g.
- mangling of templates whose signatures involve dependent types https://godbolt.org/z/sTerdjET7
- whether it's OK to throw a move-only type https://quuxplusone.github.io/blog/2019/05/11/msvc-what-are-you-doing/
- destruction order of `f() << g()` versus `operator<<(f(), g())` on callee-destroy ABIs

Because sometimes the non-conformingness is blatant, but also relatively harmless/obscure, and basically impossible to fix — it's the C++-vendor equivalent of jaywalking — and there's no point expending WG21 effort on it when WG21 could be, I dunno, standardizing Unicode identifiers or whatever it is we do these days.

OTOH, I initially read your question as a non-rhetorical question asking how you'd file an MSVC bug report for this. In which case I would have answered: No, you shouldn't just say "MSVC does X which is non-conforming"; you should work it up into a minimal compilable example that
- is 100% conforming C++
- is miscompiled by MSVC.
In particular, the example shouldn't use anything like `__declspec(...)` or `dlopen` or anything, because those seem like explicit cues to the vendor that we're doing platform-specific stuff where we don't intend this program to behave "conformingly" anymore.
Now, to craft such an example might be impossible. So the next best kind of example would be to make a minimal toy library where the library itself is doing something semi-useful (or recognizably similar to something that libraries really do), and then show how to link-or-include that library into a larger program where the larger program is doing something platform-specific, but that causes the library to egregiously misbehave.

For an example of something like (but not exactly like) the latter, I'll point to this Clang bug report which relies on a toy hash table "library":
https://quuxplusone.github.io/blog/2023/07/05/p2752-at-varna/#speaking-of-string-literals-it-w

Cheers,
Arthur