On Apr 19, 2013, at 2:02 PM, Robin Sommer <[email protected]> wrote: >> Provided that &default for tables is not supposed to modify table >> membership when accessing indices that don't exist, > > I'm wondering if it should modify the table here. I can see how the > current behaviour is misleading, it violates the "principle of least > surprise". :)
Does seem more intuitive to me. > 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? Probably. > The downside would be that if > somebody is relying on the current behaviour, he might access lots of > non-existing entries with the assumption that the table won't change > (i.e., he won't run into memory trouble). Maybe we can provide a script-layer flag that, when on, generates warnings for script locations that end up assigning &default values to non-existing indices? That at least would help someone pinpoint locations they need to change to work w/ new behavior. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
