From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20937 invoked by alias); 29 Oct 2008 21:56:36 -0000 Received: (qmail 20887 invoked by uid 48); 29 Oct 2008 21:56:25 -0000 Date: Wed, 29 Oct 2008 21:56:00 -0000 Message-ID: <20081029215625.20886.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dodji at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01947.txt.bz2 ------- Comment #6 from dodji at gcc dot gnu dot org 2008-10-29 21:56 ------- I think the problem is due to the fact that in general, grokdeclarator() in gcc/cp/decl.c does not properly set the type variant node for typedef statements. To understand this way of representing the relationship between a type and its typedef names, please read the comment of function clone_underlying_type, in gcc/c-decl.c. So grokdeclarator() does not properly create the typedef type variant for the typedef statement. Later, build_functional_cast in gcc/cp/typeck2.c looses the information about the typedef. It just takes in account the initial type. So later at templater instanciation time, there is no chance left to check the access of the typedef name, as we only know about the initial type. So in grokdeclarator() I think we should properly create the typedef type variant for the typedef statement encountered during the parsing of a class member. Then later at template instanciation time we can have a chance to check for the access of the typedef name as its information is still present via the typedef type variant associated to the initial type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693