Re: Trying to enable access enforcement on typedefs.

Re: Trying to enable access enforcement on typedefs.

[Mike Stump]

> Date: Wed, 11 Aug 1999 00:27:14 +0200
> From: "Ram'on Garc'ia Fern'andez" <ramon@jl1.quim.ucm.es>
> To: gcc@gcc.gnu.org

> I have been looking at the GCC source code in order to contribute
> access enforcement for typedefs. But to my surprise, it appears to
> be intentionally disabled.

:-)  Not surprising to me.

> I suppose that that there are some (probably subtle) problems in the
> implementation, and so GCC developers have choosen that it is better
> to allow incorrect code than something worse, such as generating
> incorrect code or giving an error for a correct program.

> Which are there problems?

I don't understand this question.  I think you mean, why is it
disabled.  Because no one wants to take the support hit to turn it on,
or put another way, someone tried to turn it on, found out it was
going to be more time to `fix' it, then they initially thought, and
decided to just turn it back off.  Jason is that person, I suspect.
If he isn't, then I suspect the code goes back to before 1992.

Anyway, to fix it, turn it on, test it throughly, resolve all problems
found, get wider testing, fix new problems found, repeat.

:-)

Re: Trying to enable access enforcement on typedefs.

[Mike Stump]

> Date: Wed, 11 Aug 1999 00:27:14 +0200
> From: "Ram'on Garc'ia Fern'andez" <ramon@jl1.quim.ucm.es>
> To: gcc@gcc.gnu.org

> I have been looking at the GCC source code in order to contribute
> access enforcement for typedefs. But to my surprise, it appears to
> be intentionally disabled.

:-)  Not surprising to me.

> I suppose that that there are some (probably subtle) problems in the
> implementation, and so GCC developers have choosen that it is better
> to allow incorrect code than something worse, such as generating
> incorrect code or giving an error for a correct program.

> Which are there problems?

I don't understand this question.  I think you mean, why is it
disabled.  Because no one wants to take the support hit to turn it on,
or put another way, someone tried to turn it on, found out it was
going to be more time to `fix' it, then they initially thought, and
decided to just turn it back off.  Jason is that person, I suspect.
If he isn't, then I suspect the code goes back to before 1992.

Anyway, to fix it, turn it on, test it throughly, resolve all problems
found, get wider testing, fix new problems found, repeat.

:-)

Re: Trying to enable access enforcement on typedefs.

[Jason Merrill]

>>>>> Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es> writes:

 > I suppose that that there are some (probably subtle) problems in the 
 > implementation, and so GCC developers have choosen that it is better 
 > to allow incorrect code than something worse, such as generating incorrect
 > code or giving an error for a correct program. 

 > Which are there problems?

This needs to work:

  class A {
    typedef int priv;
  public:
    static priv i;
  };

  A::priv A::i;

Jason

Re: Trying to enable access enforcement on typedefs.

[Mark Mitchell]

The parser currently does name-lookup for types without having context
about the functions that is about to start.  Therefore doing access
control on types will not work correctly.  It will be simple to enable
the checks once that information is available.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Trying to enable access enforcement on typedefs.

[Ram'on Garc'ia Fern'andez]

I have been looking at the GCC source code in order to contribute
access enforcement for typedefs. But to my surprise, it appears to
be intentionally disabled.

gcc/cp/decl.c(line 5881): the function lookup_name_real contains a call 
to the function lookup_member, with the third parameter, protected = 0:

  val = lookup_member (type, name, 0, prefer_type); 

gcc/cp/search.c(line 992): the function access_p refuses to perform access
checking for types, and a comment says that it has not been implemented:

  /* We don't do access control for types yet.  */
  if (TREE_CODE (decl) == TYPE_DECL)
    return 1;


However, I enabled access check to types from gdb, using set protected = 1
for the first place and a jump command for the second. cc1plus did the access
check correctly and my code did not compile as expected.

I suppose that that there are some (probably subtle) problems in the 
implementation, and so GCC developers have choosen that it is better 
to allow incorrect code than something worse, such as generating incorrect
code or giving an error for a correct program. 


Which are there problems?

Ramon

Re: Trying to enable access enforcement on typedefs.

[Jason Merrill]

>>>>> Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es> writes:

 > I suppose that that there are some (probably subtle) problems in the 
 > implementation, and so GCC developers have choosen that it is better 
 > to allow incorrect code than something worse, such as generating incorrect
 > code or giving an error for a correct program. 

 > Which are there problems?

This needs to work:

  class A {
    typedef int priv;
  public:
    static priv i;
  };

  A::priv A::i;

Jason

Re: Trying to enable access enforcement on typedefs.

[Mark Mitchell]

The parser currently does name-lookup for types without having context
about the functions that is about to start.  Therefore doing access
control on types will not work correctly.  It will be simple to enable
the checks once that information is available.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Trying to enable access enforcement on typedefs.

[Ram'on Garc'ia Fern'andez]

I have been looking at the GCC source code in order to contribute
access enforcement for typedefs. But to my surprise, it appears to
be intentionally disabled.

gcc/cp/decl.c(line 5881): the function lookup_name_real contains a call 
to the function lookup_member, with the third parameter, protected = 0:

  val = lookup_member (type, name, 0, prefer_type); 

gcc/cp/search.c(line 992): the function access_p refuses to perform access
checking for types, and a comment says that it has not been implemented:

  /* We don't do access control for types yet.  */
  if (TREE_CODE (decl) == TYPE_DECL)
    return 1;


However, I enabled access check to types from gdb, using set protected = 1
for the first place and a jump command for the second. cc1plus did the access
check correctly and my code did not compile as expected.

I suppose that that there are some (probably subtle) problems in the 
implementation, and so GCC developers have choosen that it is better 
to allow incorrect code than something worse, such as generating incorrect
code or giving an error for a correct program. 


Which are there problems?

Ramon