www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - structs and protection

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and 
modules and unions it turns out) ignore protection attributes. I assumed it 
was a bug but looking at the dmd code the only access checks are in class.c 
and none in struct.c or module.c. In other words if I declare a top-level 
symbol or a struct field as private it can still be accessed from different 
modules.
Is this a bug? 
Jul 15 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <db88qn$24tj$1 digitaldaemon.com>, Ben Hinkle says...
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and 
modules and unions it turns out) ignore protection attributes. I assumed it 
was a bug but looking at the dmd code the only access checks are in class.c 
and none in struct.c or module.c. In other words if I declare a top-level 
symbol or a struct field as private it can still be accessed from different 
modules.
Is this a bug? 

Looks, feels, and smells like a bug to me! - EricAnderton at yahoo
Jul 15 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <db8m0c$2eqf$1 digitaldaemon.com>, pragma says...
In article <db88qn$24tj$1 digitaldaemon.com>, Ben Hinkle says...
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and 
modules and unions it turns out) ignore protection attributes. I assumed it 
was a bug but looking at the dmd code the only access checks are in class.c 
and none in struct.c or module.c. In other words if I declare a top-level 
symbol or a struct field as private it can still be accessed from different 
modules.
Is this a bug? 

Looks, feels, and smells like a bug to me!

I think the 'bug' may be that the protection attribute is not flagged as "incorrect syntax" because the docs. or BNF don't mention anything about a protection attribute for members of structs or unions. - Dave
- EricAnderton at yahoo

Jul 15 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:db8nn6$2gdf$1 digitaldaemon.com...
 In article <db8m0c$2eqf$1 digitaldaemon.com>, pragma says...
In article <db88qn$24tj$1 digitaldaemon.com>, Ben Hinkle says...
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and
modules and unions it turns out) ignore protection attributes. I assumed 
it
was a bug but looking at the dmd code the only access checks are in 
class.c
and none in struct.c or module.c. In other words if I declare a top-level
symbol or a struct field as private it can still be accessed from 
different
modules.
Is this a bug?

Looks, feels, and smells like a bug to me!

I think the 'bug' may be that the protection attribute is not flagged as "incorrect syntax" because the docs. or BNF don't mention anything about a protection attribute for members of structs or unions.

Then phobos will need some cleanup since, for example, the struct in dateparse.d has some private members. Just as worrisome to me, though, is the fact that modules can't completely hide a symbol by marking it as private. The following code works fine import std.stdio; void main() { std.stdio.writex(stdout,null,null,0); } but import std.stdio; void main() { writex(stdout,null,null,0); } fails to compile with the error "std.stdio.writex is private". If the current implementation of private stands and one can't enfore private for non-classes then many of my projects will need a re-architecture to avoid structs and top-level symbols. In particular MinTL will be nearly useless since it has almost purely structs with many private members.
Jul 15 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:db9gd5$67k$1 digitaldaemon.com...
 private. The following code works fine
  import std.stdio;
  void main() {
    std.stdio.writex(stdout,null,null,0);
  }
 but
  import std.stdio;
  void main() {
    writex(stdout,null,null,0);
  }
 fails to compile with the error "std.stdio.writex is private".

That scares me.
 If the current implementation of private stands and one can't enfore 
 private for non-classes then many of my projects will need a 
 re-architecture to avoid structs and top-level symbols. In particular 
 MinTL will be nearly useless since it has almost purely structs with many 
 private members.

I think the whole mess of protection attributes need work. Classes can't access private members of their own nested classes, although they should be friends (same module); struct protection attributes don't work; module protection attributes can be circumvented; and I don't think the "package" keyword does _anything_.
Jul 15 2005
parent Dave <Dave_member pathlink.com> writes:
In article <db9git$6f3$1 digitaldaemon.com>, Jarrett Billingsley says...
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:db9gd5$67k$1 digitaldaemon.com...
 private. The following code works fine
  import std.stdio;
  void main() {
    std.stdio.writex(stdout,null,null,0);
  }
 but
  import std.stdio;
  void main() {
    writex(stdout,null,null,0);
  }
 fails to compile with the error "std.stdio.writex is private".

That scares me.
 If the current implementation of private stands and one can't enfore 
 private for non-classes then many of my projects will need a 
 re-architecture to avoid structs and top-level symbols. In particular 
 MinTL will be nearly useless since it has almost purely structs with many 
 private members.

I think the whole mess of protection attributes need work. Classes can't access private members of their own nested classes, although they should be friends (same module); struct protection attributes don't work; module protection attributes can be circumvented; and I don't think the "package" keyword does _anything_.

From what I've seen so far, 'package' does do what the docs. say it should - it's does for a package what 'private' does for a file (it's 'private' for a package). I agree - the other three look like inconsistencies at best.
Jul 15 2005
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <db9gd5$67k$1 digitaldaemon.com>, Ben Hinkle says...
"Dave" <Dave_member pathlink.com> wrote in message 
news:db8nn6$2gdf$1 digitaldaemon.com...
 In article <db8m0c$2eqf$1 digitaldaemon.com>, pragma says...
In article <db88qn$24tj$1 digitaldaemon.com>, Ben Hinkle says...
Walter,
The thread "Slashdot on the future of C++" pointed out that structs (and
modules and unions it turns out) ignore protection attributes. I assumed 
it
was a bug but looking at the dmd code the only access checks are in 
class.c
and none in struct.c or module.c. In other words if I declare a top-level
symbol or a struct field as private it can still be accessed from 
different
modules.
Is this a bug?

Looks, feels, and smells like a bug to me!

I think the 'bug' may be that the protection attribute is not flagged as "incorrect syntax" because the docs. or BNF don't mention anything about a protection attribute for members of structs or unions.

Then phobos will need some cleanup since, for example, the struct in dateparse.d has some private members. Just as worrisome to me, though, is the fact that modules can't completely hide a symbol by marking it as private. The following code works fine import std.stdio; void main() { std.stdio.writex(stdout,null,null,0); } but import std.stdio; void main() { writex(stdout,null,null,0); } fails to compile with the error "std.stdio.writex is private". If the current implementation of private stands and one can't enfore private for non-classes then many of my projects will need a re-architecture to avoid structs and top-level symbols. In particular MinTL will be nearly useless since it has almost purely structs with many private members.

I should have complained a while back I guess.. I just thought it was something the compiler was ignoring and would hopefully be cleared up soon or perhaps access protection was on the docket for structs (which makes the most sense, IMO). You've made a better case than I could have at the time though - at least two important libraries were built with structs, and at least parts of them were built with struct access protection in mind.
Jul 15 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:db88qn$24tj$1 digitaldaemon.com...
 Walter,
 The thread "Slashdot on the future of C++" pointed out that structs (and
 modules and unions it turns out) ignore protection attributes. I assumed

 was a bug but looking at the dmd code the only access checks are in

 and none in struct.c or module.c. In other words if I declare a top-level
 symbol or a struct field as private it can still be accessed from

 modules.
 Is this a bug?

Yes.
Jul 15 2005
parent reply Mike Capp <mike.capp gmail.com> writes:
In article <dba5rj$tou$1 digitaldaemon.com>, Walter says...
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 Is this a bug?

Yes.

Good to hear. Can we assume that a struct with private members won't allow static-initializer syntax? (Incidentally, why is the static-initialization syntax only allowed on static variables? At local scope, why can I say "int i = 1;" but not "Foo foo = {1, 2};"? Not a biggie by any means, just curious.) I'd still quite like struct constructors. Static opCall looks the same, but unlike a real ctor it doesn't provide a convenient hook on which the compiler can hang an invariant check, so you don't get contracts enforced at the point of creation.
Jul 16 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message 
news:dbb8a6$1pa1$1 digitaldaemon.com...
 (Incidentally, why is the static-initialization syntax only allowed on 
 static
 variables? At local scope, why can I say "int i = 1;" but not "Foo foo = 
 {1,
 2};"? Not a biggie by any means, just curious.)

I had a thread about this maybe a week or two ago. I think we kind of came to the conclusion that while Foo f={1,2,3}; Is obvious, something like fork({1,2,3}); Isn't. We were thinking something like fork(cast(Foo){1,2,3}); But that's kind of ugly and might present parsing problems. Of course, both problems could be solved with struct ctors ;)
 I'd still quite like struct constructors. Static opCall looks the same, 
 but
 unlike a real ctor it doesn't provide a convenient hook on which the 
 compiler
 can hang an invariant check, so you don't get contracts enforced at the 
 point of
 creation. 

Jul 17 2005
parent Chris Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 Foo f={1,2,3};
 
 Is obvious, something like
 
 fork({1,2,3});
 
 Isn't.  We were thinking something like
 
 fork(cast(Foo){1,2,3});
 
 But that's kind of ugly and might present parsing problems.

That's pretty much exactly it (although if the only definition of fork() available expects a Foo, then its pretty easy to deduce... but the argument-on-topic stays valid). And why am I responding? To take one more stab at my preferred solution-syntax, of course. :) # fork(new Foo {1,2,3}); Ta-da. Could work well with arrays too. # func(new int[] [1,2,3]); Although for arrays there's a simple template function one can use, but that doesn't really solve anything. And I still want to see AA literals, something like: # int[char[]] map = new int[char[]] [ # `foo` : 1 , # `bar` : 2 , # `bob` : 5 , # `eris` : 42 # ]; The only potential issue with using 'new' is that it is usually understood to represent a heap allocation. So maybe it needs a companion keyword or some other method to do a stack allocation as one normally would for structs and such. -- Chris Sauls
Jul 17 2005