https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407

Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arthur.j.odwyer at gmail dot 
com

--- Comment #1 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
According to Richard's comment on https://bugs.llvm.org/show_bug.cgi?id=46036 ,
http://cwg-issue-browser.herokuapp.com/cwg1873 indicates that Clang may be
correct according to the Standard as written. HOWEVER...

The "misbehavior" here isn't really about `friend`; it's about the interaction
between `static` and `protected`. If you change your test case to make `value`
non-static, then all vendors agree that the non-static `value` is inaccessible.

With a static protected member (Clang rejects, GCC and MSVC accept):
https://godbolt.org/z/essofs
With a non-static protected member (all three correctly reject):
https://godbolt.org/z/T1GWTP

And here's a test case that doesn't use `friend` at all, but rather uses a
private inheritance path, so that `C` is derived from `A`, but `C` itself is
not aware of the fact. This case came up on Slack on 2020-08-14:
https://cpplang.slack.com/archives/C5GN4SP41/p1597391677014800

With a static protected member (GCC and Clang accept, MSVC rejects):
https://godbolt.org/z/6d786M
With a non-static protected member (all three correctly reject):
https://godbolt.org/z/MeTxeW

// https://godbolt.org/z/6d786M
struct A {
protected:
    static int sf();
};
struct B : private A {};

struct C : public B {
    static void test();
};

void C::test() { &::A::sf; }

Reply via email to