User account creation filtered due to spam.

Bug 41437 - No access control for classes in template functions
Summary: No access control for classes in template functions
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid
: 40843 45775 52373 64216 (view as bug list)
Depends on:
Blocks: 59002
  Show dependency treegraph
 
Reported: 2009-09-22 20:10 UTC by Guillaume Melquiond
Modified: 2016-06-27 17:03 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 3.4.6, 4.4.3, 4.5.2, 4.6.0
Last reconfirmed: 2010-09-20 15:53:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Melquiond 2009-09-22 20:10:20 UTC
In the following testcase, A::B is a private type of A, yet function f has no trouble manipulating it. The error is detected by gcc neither in the definition of f nor in its instantiation in g.

class A { struct B { B(); }; };
template<typename T> void f() { A::B b; }
void g() { f<int>(); }

Tested with the 4.3.3 release and the 20090912 snapshot of 4.5.0.
Comment 1 Andrew Pinski 2009-09-25 04:44:37 UTC
I think this is a duplicate of bug 40843.
Comment 2 Jonathan Wakely 2010-09-20 15:54:16 UTC
*** Bug 40843 has been marked as a duplicate of this bug. ***
Comment 3 Jonathan Wakely 2010-09-24 09:35:15 UTC
*** Bug 45775 has been marked as a duplicate of this bug. ***
Comment 4 Jonathan Wakely 2012-02-24 16:50:25 UTC
*** Bug 52373 has been marked as a duplicate of this bug. ***
Comment 5 Shane 2013-06-21 18:17:31 UTC
This bug still exists for g++ 4.8.1.  Crops up regardless of where the template function is that tries to access the protected/private member:

class Base { void snarf() {} };

struct Derived : public Base
{
  template <class T>
  void bar( T & t )
  {
    snarf(); // this is incorrectly marked ok
  }
};
Comment 6 Jonathan Wakely 2014-12-08 10:28:51 UTC
*** Bug 64216 has been marked as a duplicate of this bug. ***
Comment 7 Barry Revzin 2016-03-14 01:24:35 UTC
This bug still exists in 5.3.0. For instance:

class X {
    int mem;
};

template <class T>
auto foo(T) {
    return &X::mem;
}

int main() {
    foo(0);
}
Comment 8 Vlad Gheorghiu 2016-06-25 00:55:15 UTC
The bug exists in gcc 6.1 as well:

class X
{
    template<class>
    class A{};
};

int main()
{
    X::A<int> a; // compiles just fine
}
Comment 9 Martin Sebor 2016-06-27 17:03:03 UTC
I'm not sure the original test case and the one in comment #8 are the same bug.  The former doesn't seem to have ever been rejected, while the latter used to until r231354 when it became accepted.

r231354 | jason | 2015-12-06 23:35:14 -0500 (Sun, 06 Dec 2015) | 4 lines

	Fix parse/no-type-defn1.C with -std=c++1z.

	* parser.c (struct tentative_firewall): New.
	(cp_parser_template_id, cp_parser_decltype_expr): Use it.

I'm also not sure bug 45775 referenced in comment #3 is a duplicate of this one.  I haven't been able to find a GCC revision that accepts the test case there.

Finally, bug 40843 was fixed by r190830 which was committed to resolve bug 50545 and bug 51222, so it also doesn't seem to be a duplicate of this one.