[
https://bro-tracker.atlassian.net/browse/BIT-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Siwek updated BIT-327:
--------------------------
Fix Version/s: (was: 2.4)
2.5
> 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)
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
