Bug 2830 – private attribute doesn't work for structs/unions/classes

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
All
OS
All
Creation time
2009-04-10T07:50:17Z
Last change time
2019-07-16T04:31:22Z
Assigned to
No Owner
Creator
anonymous4
Depends on
313, 314
Blocks
1441, 3108

Comments

Comment #0 by dfj1esp02 — 2009-04-10T07:50:17Z
tmp1.d --- private struct TestStruct { int var; } --- tmp.d --- import tmp1; int main() { TestStruct s; s.var=0; return 0; } ---
Comment #1 by gide — 2009-04-10T09:59:42Z
Structs, unions, classes and variables can bypass the private attribute. Similar to BUG 313 and BUG 314, added dependancies. tmp1.d ------ private struct TestStruct { int var; } private union TestUnion { int var; } private class TestClass { int var; } private int var; tmp.d ----- import tmp1; void main() { TestStruct s; TestUnion u; auto c = new TestClass; s.var = var; // Fails s.var = a.var; // OK }
Comment #2 by jarrett.billingsley — 2009-04-10T11:17:12Z
This is almost certainly a dup of BUG 1441. The same lack of privacy mechanism applies to all kinds of UDTs. It doesn't really have anything to do with BUG 313 or BUG 314.
Comment #3 by smjg — 2009-04-10T14:18:25Z
What is 'a'? That line doesn't seem to have anything to say. But this code, compiled with the same tmp1.d, has something to say: ---------- import tmp1; void main() { TestStruct s; TestUnion u; auto c = new TestClass; auto sv = s.var; auto uv = u.var; auto cv = c.var; auto v = var; }
Comment #4 by gide — 2009-04-11T04:11:51Z
> tmp.d > ----- > import tmp1; > > void main() { > TestStruct s; > TestUnion u; > auto c = new TestClass; > s.var = var; // Fails > s.var = a.var; // OK // Typo. s.var = tmp1.var; //Compiles but shouldn't bug 314 > } Looks like a dup of bug 1440, my google-fu is weak.
Comment #5 by dfj1esp02 — 2009-04-11T04:54:06Z
^^it's actually my google-fu. Changing to spec bug. Spec should be clarified, how protection attributes work in this case.
Comment #6 by smjg — 2009-04-12T17:53:04Z
Discussion taken to: "The great inapplicable attribute debate" digitalmars.D:87915 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=87915
Comment #7 by issues.dlang — 2011-05-08T14:48:51Z
This is a bug in both D1 and D2, so I'm marking it as such. TestStruct shouldn't even be constructable outside of tmp1.d. The question of allowing you to access its member variables is secondary. It looks like the struct itself is being left as public, when it should be private. Now, it's still a bug if you can access its private member variables, but you shouldn't even be able to construct it in the first place.
Comment #8 by bugzilla — 2012-01-23T00:36:23Z
It's not a spec bug. Private declarations should not be visible outside their module.
Comment #9 by issues.dlang — 2012-01-23T07:51:48Z
> It's not a spec bug. Private declarations should not be visible outside their > module. Do you mean not visible or not accessible? At present, private seems to work like C++ in that it's _always_ visible but not accessible. It's included in overload sets too.
Comment #10 by bugzilla — 2012-01-23T11:25:49Z
I meant accessible.
Comment #11 by bugzilla — 2012-09-04T22:17:05Z
Comment #12 by Oleg.Kuporosov — 2012-10-17T22:08:03Z
Peter's fixes from "Comment 11" is verified in dmd2.061 alpha, but looks wasn't merged into D1 branch, so tests still failed in dmd1.076 alpha. This record wss issued against D1 so status is unchanged.
Comment #13 by pro.mathias.lang — 2019-07-16T04:31:22Z
Fixed in D2