On Wed, 12 Jul 2023 at 17:56, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> 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).
>
That's very insightful and I'm convinced.

>
> > (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?
>

The only way I see to make the wording less broad is to use a new term like
'linkage-unit' or 'binary', which you seem to object to. Can you see a
different way?


>
> 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? Is anyone comfortable with deliberately
choosing to leave these standard clauses a dead-letter which can't be
conformed-to by a major implementation? The standard did make pragmatic
choices in the past to align with reality (removing garbage collection API,
'extern' templates (until modules) etc.), I believe this is a case where
such an alignment-with-reality is in order.


> 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.
>
I've reached out to the visual-cpp team and await some formal response.
Anyway it is pretty clear these issues aren't fixable - at the very least
for legacy code reasons.

>
> HTH,
> Arthur
>