[Bro-Dev] #327: Binding attributes to values/variables

[Bro Tracker]

#327: Binding attributes to values/variables
----------------------+------------------------
  Reporter:  robin    |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:  Bro2.2
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by jsiwek):

 Replying to [comment:1 robin]:
 > To clarify, the attached thread does not necessarily reflect a
 > resolution we fully converged on. We will need to rediscuss the
 > right approach before tackling this.

 Feel like discussing more?

 > From Vern:
 >
 >     In abstract terms, we need to marry two notions: per-variable
 >     attributes (those introduced when defining the variable) and
 >     per-value attributes (those introduced when creating a value).
 >     These both exist under-the-hood, but the rules for propagating
 >     them are ad hoc.

 My description of it would be that the contexts in which attributes are
 used are ad hoc while the propagation rules for most contexts are just
 mostly non-existing.

 Specifically for the context of local/global variable declarations, the
 only propagation that occurred was at init/parse time when the declaration
 also included an initialization.  This seems to cause the most confusion
 for people as they expect values assigned to such a variable at run time
 to inherit the attributes.  I did some changes in `topic/jsiwek/attr-
 propogation` (sic) that I think fixes the propagation expectations for
 this context with the rules being that attributes in declarations will
 propagate in the "type -> variable -> value" direction for values assigned
 at either init-time or run-time.

 Some of the other contexts that use attributes don't have such a clear
 propagation expectation (record fields are currently ambiguous and
 function/events don't seem to require any propagation technique).  So I
 think if there were a strong need to be able to apply attributes
 specifically to a value, those cases should be approached by adding the
 new "add <attr_list> <id>;" statement or with BIFs.

 > That said, I'm not really sure that this should ideally look like.
 > Intuitively, I'd actually say attributes belong to values, not
 > variables, because transfer-on-assignment can lead to subtle effects
 > (values are passed around, and what if the receiving function
 > happens to assign the value to the wrong variable?. Also what if you
 > assign a value with attribute X to a variable without X; shouldn't
 > the value then be *deleted* for consistency reasons?).

 I would think of it as values being able to inherit attributes from
 variables with the variable's attributes taking precedence over a value's
 in case of conflict.  But that doesn't preclude a value from being able to
 own separate attributes.

 > A declaration such as
 >
 >       const foo = F &redef;
 >
 > can be interpreted as "we can rebind foo if it's current value has
 > the &redef attribute".
 >
 > I haven't thought this through actually but I guess my question is
 > whether we need per-variable attributes at all?

 There's the cases were a "variable" may not have a value yet (table types
 are an exception to this).  The way around that would be the dynamic
 attribute application methods mentioned before (a BIF or "add <attr_list>
 <id>;" statement) and then probably get rid of attributes in variable
 declarations completely because otherwise you still would need the
 variable identifier to hold on to attributes until the first value
 assignment.  That approach seems a little inconvenient/cumbersome.

 There's also record field attributes which apply more to the field itself
 and not the value assigned to it.

 So do you think that my branch would be worth merging on the grounds that
 it aligns local/global variable attribute propagation with people's
 expectation, but it doesn't claim to unify attributes to a single usage
 context (maybe it's too late for that)?

-- 
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/327#comment:4>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker