On Mon, Jul 17, 2023 at 4:57 AM Ofek Shilon <ofekshilon_at_[hidden]> wrote:

> On Wed, 12 Jul 2023 at 17:56, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> 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

>