Threading Types: add a bit of documentation to subnet type.

This explains how the length field is currently handled when exchanging
data in both directions.
This commit is contained in:
Johanna Amann 2017-04-10 11:37:43 -07:00
parent 7826cbdfb6
commit a7b1161c12

View file

@ -98,7 +98,7 @@ struct Value {
typedef set_t vec_t; typedef set_t vec_t;
struct port_t { bro_uint_t port; TransportProto proto; }; struct port_t { bro_uint_t port; TransportProto proto; };
struct addr_t { struct addr_t {
IPFamily family; IPFamily family;
union { union {
struct in_addr in4; struct in_addr in4;
@ -106,6 +106,13 @@ struct Value {
} in; } in;
}; };
// A small note for handling subnet values: Subnet values emitted from
// the logging framework will always have a length that is based on the
// internal IPv6 representation (so you have to substract 96 from it to
// get the correct value for IPv4).
// However, the Input framework expects the "normal" length for an IPv4
// address (so do not add 96 to it), because the underlying constructors
// for the SubNet type want it like this.
struct subnet_t { addr_t prefix; uint8_t length; }; struct subnet_t { addr_t prefix; uint8_t length; };
/** /**