[Bro-Dev] #981: &default record only creates one record

[Bro Tracker]

#981: &default record only creates one record
-----------------------+------------------------
  Reporter:  dmandelb  |      Owner:
      Type:  Problem   |     Status:  new
  Priority:  Low       |  Milestone:  Bro2.2
 Component:  Bro       |    Version:  git/master
Resolution:            |   Keywords:
-----------------------+------------------------

Comment (by jsiwek):

 Transferring previous discussion from bro-dev list since I think otherwise
 it will get lost/forgotten:

 >>Can we change tables so that if &default is a non-constant, the first
 >>time one accesses a non-existing index, that slot gets assigned a
 >>deep-copy of the &default value?
 >
 >I'm not a fan of this, as "&default is a non-constant" is a more nuanced
 >semantic notion (and could get messy for complicated constructors) than
 >the sort that I think language rules should draw upon.  Rather, my
 thinking
 >is that &default should apply to rvalues but not lvalues.  I believe (but
 >have not confirmed) that there's enough context in the parser to tell
 whether
 >the access is in an lvalue context or an rvalue context.  If so, then the
 >former shoud be a run-time error; if the user wants to update a value in
 the
 >table that's not already there, they need to first put the value in the
 table.

 There's only really an implicit lvalue context that doesn't extend to sub-
 expressions.  If it were made explicit and extended to sub-expressions,
 I'm still sketchy on what rules would determine whether a table lookup
 that results in &default being used is a runtime error or not.  The
 example provided originally in this ticket is one that would be nice to
 have produce a run-time error, but then there's things like:

 {{{
 global foo: table[count] of string &default="test";
 global bar: table[string] of count;

 bar["test"] = 7;
 bar[foo[0]] = 13;
 }}}

 That shouldn't result in a runtime error even though the `foo[0]` sub-
 expression results in the use of the &default within the context of the
 outer lvalue expression.

 Would the rule be that we have to propagate the lvalue "context" to the
 operand of all unary expressions and only the left operand of binary
 expressions?

 >>An alternative would be to have the lookup return a copy of the
 >>default, but not modify the table.
 >
 >That makes sense to me in any case.  In fact, I'm surprised this isn't
 >what already happens.

 This is simple to change, are we ok with going this route?  i.e. this
 solution invalidates the premise of this ticket and #980 regarding whether
 &default modifies table membership.

-- 
Ticket URL: <http://tracker.bro.org/bro/ticket/981#comment:1>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker