On Wed, Jul 12, 2023 at 10:34 AM Ofek Shilon via Std-Proposals <
std-proposals_at_[hidden]> 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?
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?

 (b) [replacement.functions] http://eel.is/c++draft/replacement.functions#3,
> lists flavours of new/delete that can be interposed (==overridden) from
> user code:
> "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