[Bro-Dev] #908: Need for function bytestring_to_double

[Bro Tracker]

#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
 conversion BIFs.
 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