Arturo Salz wrote: > Gord, > > I agree with your assessment. If any component along the access path is > protected or local then access to the end-point is disallowed. Hmmm - that is stronger than what I said. A protected intermediate should be allowed if the orginating reference would be allowed access to the protected element. So if we had: class D extends C; task foo; C c = new; c.p.pub = 1; // c.p is protected but c.p.pub is not endtask; endclass That should be valid since within "D" the code is permitted to access the protected members of "C". My original statement was that "every component along the access path is valid to access from that point in source"; that is weaker than "no local or protected access" but stronger than just checking the end point. Gord. > > Arturo > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Gordon Vreugdenhil > Sent: Monday, November 27, 2006 2:39 PM > To: SV_EC List > Subject: [sv-ec] local/protected intermediate reference enforcement > > > The 1800 LRM is not clear on the rules for when "local" and > "protected" are to be enforced. In particular, in a sequence > of member accesses, if a middle reference would be invalid, is the > entire reference invalid? > > Example: > > class P; > int pub; > endclass > > class C; > protected P p; > function new(); > p = new; > endfunction > endclass > > module top; > C c = new; > initial begin > c.p.pub = 1; // c.p is protected but c.p.pub is not > end > endmodule > > > I think that SV should be restrictive here -- an access is > only valid from a particular point in the source if every > component along the access path is valid to access from > that point in source. This is what C++ enforces as well. > > Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Tue Nov 28 09:33:53 2006
This archive was generated by hypermail 2.1.8 : Tue Nov 28 2006 - 09:34:09 PST