[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