[Bro-Dev] #908: Need for function bytestring_to_double
bro at tracker.bro-ids.org
Sun Oct 28 12:23:13 PDT 2012
#908: Need for function bytestring_to_double
Reporter: carsten | Owner:
Type: Feature Request | Status: needs information
Priority: Normal | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
Comment (by carsten):
Replying to [comment:7 jsiwek]:
> > - the bit-pattern is first translated from network to host order
before it is interpreted as double, to avoid invalid bitpatterns as may
occur in ntohd().
> I don't get that entirely, I would have thought doing a `memcpy` in to
`double` storage and then using `ntohd` would work, but maybe not.
I once observed a problem when assinging a still-to-be-swapped bitpattern
to a double before swapping it from network to host order. The problem
vanished when using the workaround with uint64. My interpretation of the
problem was the following:
Not all 2 * * 64 possible bitpatterns have an unambiguous meaning
according to IEEE 754, see the NaN ans SNaN patterns and - depending on
the implememtation - the subnormal patterns in
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF. That could
mean that there may be a valid bitpattern for a double, in network order,
which is an ambiguous pattern if interpreted (without swapping) in host
order, if network and host oder differ by swapping. The memcpy would copy
the bitpattern unchanged to the double variable, but the next access (for
the reason of swapping it) to the double variable having this bitpattern
which could be unusual to the platform accessing it, could result in a
"correction", i.e. change of the unusual bitpattern to the "normal"
bitpattern representing the same informaation (e.g. NaN). That would mean
that the bitpattern is changed before swapping, and after swapping would
result in a different number than was originally put on the network.
Unfortunately, I have not captured the situation I observed and thus I
cannot use it for a test case. At that time I was happy to have solved the
problem with using the uint64-workaround.
If the above was true and could be reproduced, then this also would mean
that the current ntohd() function is flawed, as it assings a to-be-swapped
bitpattern to double first before swapping.
Now that we start a discussion about it, I tried to artificially recreate
the problem by creating supposed problematic bitpatterns and swapping them
back and forth. However, I was not able to recreate the change of
bitpattern that I though to have observed before.
Bottom line: I currently see no more reason anymore to use the uint64
workaround and therfore the patch proposed by Daniel should work fine.
I'll test it myself.
> Otherwise, I still wonder about the second bullet above and whether some
type casts can be avoided. And maybe the name should be
`network_bytestring_to_host_double` to be clear there may be a byteswap
operation in it. Or just make separate BIFs for byte swapping bytestrings
of various lengths and also separate bytestring to other data type
Fine with me, chose whatever name seems appropriate.
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/908#comment:10>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker
More information about the bro-dev