[Bro-Dev] #474: &raw_output turns null values into \0

Bro Tracker bro at tracker.bro.org
Thu May 16 13:34:21 PDT 2013

#474: &raw_output turns null values into \0
  Reporter:  seth     |      Owner:  jsiwek
      Type:  Problem  |     Status:  assigned
  Priority:  Normal   |  Milestone:  Bro2.2
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:  preview

Comment (by jsiwek):

 Replying to [comment:13 robin]:
 > This generally sounds good to me. I admit that I don't have a good sense
 of all pontential implications, there might be some subtle ones, but
 assuming it doesn't break anything I'm fine applying it.

 It's been a while, I'll have to check again to see if it seems to break
 any of the tests (and I think I just noticed something about it that may
 leak memory).

 > - what if a value that already has an attribute defined gets assigned to
 a local with an attribute. Does the latter still transfer over? Is it
 different depending whether it's the same attribute or not?

 The local variable's attributes (if it has some) do always transfer to the
 value during the assignment, but maybe I'd call it an "overwrite" instead
 of a "transfer" since the value may lose attributes in the process if the
 local variable did not have the same ones.

 And note that &persistent and &synchronized are special cases in that they
 associate with variables, not values, so those attrs are never get lost
 once a variable has them.

 Another weird detail is that &default for tables will cache the first
 evaluation of the default expression and re-use the resulting value on
 later lookups.  This means that new &default attrs may be propagated to a
 table val, but it may still be using a cached value from a previous
 &default attr if the table had been accessed at a missing index at least
 once.  Should we remove the caching?  That would also make non-const
 default expressions work (doesn't look like there's anything forbidding
 them currently, they just work oddly due to the caching).

 > - the one caveat I see is shared references: say one val is assigned to
 two locals with different values for the same attribute. It would depend
 on order what exactly happens, and in any case one assignment changes
 semantics somewhere else.

 Yeah, that's weird.  Maybe if attributes were more closely tied to typing
 and then prevent assignment between different type+attrs?

Ticket URL: <http://tracker.bro.org/bro/ticket/474#comment:14>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker

More information about the bro-dev mailing list