[Bro-Dev] [JIRA] (BIT-327) Binding attributes to values/variables

[grigorescu (JIRA)]

    [ https://bro-tracker.atlassian.net/browse/BIT-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20033#comment-20033 ] 

grigorescu commented on BIT-327:
--------------------------------

The discussion in BIT-327 needs to be resolved before topic/jsiwek/attr-propogation can be merged, which has at least partial fixes for all 5 tickets.

> Binding attributes to values/variables
> --------------------------------------
>
>                 Key: BIT-327
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-327
>             Project: Bro Issue Tracker
>          Issue Type: Problem
>          Components: Bro
>    Affects Versions: git/master
>            Reporter: Robin Sommer
>             Fix For: 2.5
>
>
> 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.
> I'm attaching the follow-up email thread with further thoughts on
> streamlining this.
> Robin
> [^"None"]
> Did we ever reach resolution regarding the appended thread (from, um,
> a year ago\!), or at least put something in the Tracker so we don't lose
> sight of it?
> 		Vern
> [^"None-1"]
> On Tue, Nov 03, 2009 at 17:25 \-0800, you wrote:
> > 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.
> This is something I've wondered about a few times already what the
> right thing to do is. The keyword at the moment is indeed "ad-hoc":
> I remember that a number of times I've been running into problems
> with propagating (or not propagating) attributes, and while I was
> always able to fix the immediate problem in some way, we don't have
> a clear system at the moment when that happens and when not. 
> 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?). 
> If we accept for a moment that attributes belong only to values,
> then we can think about how to set them. A global definition such as
>       const log_file = open_log_file("foo") &rotate_interval 
>            
> can be interpreted as assigning the attribute to the value returned
> from the function (more generaly to whatever what the assigned
> expression yields). 
> We can use the "add foo &raw_output" syntax you suggested for adding
> attributes to the value of foo dynamically. 
> 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? 
> Robin
> [^"None-2"]
> On Nov 4, 2009, at 7:54 PM, Robin Sommer wrote:
> >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?).
> Attributes being attached to value really seems to make sense.
> >If we accept for a moment that attributes belong only to values,
> >then we can think about how to set them. A global definition such as
> >
> >     const log_file = open_log_file("foo") &rotate_interval
> It works in this case, but this has typically been where trouble was encountered.  What about cases where there isn't a value assigned yet?  Something like...
> const bad_addrs_with_description: table[addr] of string &redef &write_expire=10mins;
> There isn't a value yet, but it has an attribute applied to it.  Would that style still be supported?  It would seem to conflict with having only value attributes.
> Even for my database backed variable stuff I'm working on, it created a stumbling block.  What I'm doing internally is creating a copy of the value including attributes to a separate internal value when a query is being run.  That value is then filled from the database and the script level variable is rebound to my newly filled internal value and the old value is deleted.  I think that would be the right way to do it in this case even if only value attributes exist because it's an internal detail and the new value is being created internally, but it's certainly confusing sometimes.
> bq. .Seth
> [^"None-3"]
> On Wed, Nov 04, 2009 at 20:26 \-0500, you wrote:
> > const bad_addrs_with_description: table[addr] of string &redef  
> > &write_expire=10mins;
> >
> > There isn't a value yet, but it has an attribute applied to it. 
> Actually there is: it's assigned an empty table. So, yes that would
> still work. 
> What would be different however is a later assignment (redef for
> const [1]), which would ignore the &write_expire of the original
> definition and instead use the attributes from the assigned value.
> Robin
> [1] A "=" redef, not a "+=" redef which works on the original value.
> [^"None-4"]
> On Nov 10, 2009, at 12:32 AM, Robin Sommer wrote:
> >What would be different however is a later assignment (redef for
> >const [1]), which would ignore the &write_expire of the original
> >definition and instead use the attributes from the assigned value.
> >
> >[1] A "=" redef, not a "+=" redef which works on the original value.
> Ah, ok.  This is all coming together for me now. :)
> Another question I have is if the change was made to allow attribute additions and deletions at runtime, does it sort of violate the concept of const?  const seems to tie together the value and variable together and make them unchangeable at runtime but it's a little confusing conceptually if you're able to still change the attributes of a const at runtime.
> Am I thinking about that right?
> bq. .Seth
> [^"None-5"]
> On Fri, Nov 13, 2009 at 13:24 \-0500, you wrote:
> > Another question I have is if the change was made to allow attribute  
> > additions and deletions at runtime, does it sort of violate the concept 
> > of const?
> That's a good point, yes. Perhaps "const foo = xxx" should actually
> mean that the value xxx gets an (internal) attribute &const so that
> it's not changeable? And then assigning to a global with a current
> value that has the &const attribute would be prohibited as well.
> Does that make sense?
> Robin



--
This message was sent by Atlassian JIRA
(v6.4-OD-15-055#64014)