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; }