Bug 29040 - missing access control checks in subclasses for nested types
Summary: missing access control checks in subclasses for nested types
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Paolo Carlini
URL:
Keywords: accepts-invalid
Depends on:
Blocks: 29843
  Show dependency treegraph
 
Reported: 2006-09-12 20:03 UTC by Jorn Wolfgang Rennecke
Modified: 2021-08-04 19:49 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 2.95.3, 3.0.4, 3.2.3, 3.3.3, 3.4.0, 4.0.0, 4.1.0, 4.2.0
Last reconfirmed: 2021-08-04 00:00:00


Attachments
Draft (328 bytes, patch)
2019-03-06 22:21 UTC, Paolo Carlini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2006-09-12 20:03:38 UTC
The following should not compile:

struct c
{
private:struct n
  {
    int j;
  };
};

struct d:public c
{
  void f (struct n *p);
};

According to 9.2 ; 1, nested types are class members. 11 ; 4 says that member access control does not affect visibility, only access. If an inaccessible member name is used, the program is ill-formed.

FWIW, g++ will also accept if you declare a data member of type struct n in d.
Comment 1 Andrew Pinski 2006-09-12 20:59:08 UTC
Confirmed, not a regression.
Comment 2 Paolo Carlini 2013-10-14 18:05:39 UTC
To be clear: the issue isn't access control of subclasses per se: the real issue is about access control for 'struct n' vs 'n' when the declaration of p is parsed: 'struct n' is handled like 'struct whatever', is accepted without even performing a lookup. Indeed, changing 'struct n' to 'n' per normal C++ for this kind of code, leads to the expected error message. I think that accepting 'struct n' without lookup and thus without access control in this kind of code used to be legal in cfront.
Comment 3 Paolo Carlini 2013-10-14 19:46:22 UTC
I have a draft patch which essentially adds the missing lookup to cp_parser_elaborated_type_specifier
Comment 4 Jakub Jelinek 2014-04-22 11:36:58 UTC
GCC 4.9.0 has been released
Comment 5 Jakub Jelinek 2014-07-16 13:30:22 UTC
GCC 4.9.1 has been released.
Comment 6 Jakub Jelinek 2014-10-30 10:40:26 UTC
GCC 4.9.2 has been released.
Comment 7 Jakub Jelinek 2015-06-26 19:55:26 UTC
GCC 4.9.3 has been released.
Comment 8 Jonathan Wakely 2019-03-06 15:41:35 UTC
Paolo, do you still have a patch for this?
Comment 9 Paolo Carlini 2019-03-06 20:18:13 UTC
Hi Jon and first, sorry for the long wait: in my opinion when we assign a bug to ourselves it should be matter of 1-2 weeks maximum before an actual patch materializes on the mailing list. I'll dig up my notes and my draft and see if I should really keep the bug.
Comment 10 Paolo Carlini 2019-03-06 22:21:21 UTC
Created attachment 45911 [details]
Draft
Comment 11 Paolo Carlini 2019-03-06 22:24:12 UTC
I attached what I had in mind: the new testcase is handled correctly and the C++ testsuite is clean. If you have comments or feedback about more involved testcases, please let me know: after 9.1.0 is out we can probably fix this in trunk.
Comment 12 Paolo Carlini 2019-03-07 19:49:24 UTC
My draft doesn't the templated case:

struct c
{
private: template<typename> struct n
  {
    int j;
  };
};

struct d:public c
{
  template<typename T>
  void f (struct n<T> *p);
};

Interestingly, currently we neither handle correctly a version of it without the class-key:

struct c
{
private: template<typename> struct n
  {
    int j;
  };
};

struct d:public c
{
  template<typename T>
  void f (/*struct*/ n<T> *p);
};

but maybe it's just a special case of our long standing issues with access control vs templates.