Recurrent hash collision
Closed this issue · 8 comments
The message
std_msgs/Empty data
and
std_msgs/Empty[1000] data
has the same hash.
Because gentools.py code ignore arrays.
In my opinion it's ugly bug.
Thank you for reporting the issue. I can confirm your result and would also expect a different hash for those two messages. I don't know why the hash algorithm was written the way. Maybe someone else knows @ros/ros_team?
But I fear we can't change the behavior now since that would change the hash for a lot of messages and would make them incompatible with previous releases.
I thought we already decided elsewhere that changing the has was acceptable?
Also, why is having a hash collision here a bug? Hashes are allowed to be the same.
I'm not sure that it's a hash collision, seems like an implementation bug:
- https://github.com/ros/genmsg/blob/indigo-devel/src/genmsg/gentools.py#L80
- any type have the same hash with array (
[]) or without, logical conflict because array is not the same that value, do you think?
@eric-wieser Changing the algorithm to compute the hash needs to happens across all language specific implementations. It also implies that whenever it is being changed that older and newer versions of ROS can't exchange that message type anymore (since they don't agree on the md5).
Two different message definitions having the same md5 means a publisher publishes one type while a subscriber trying to subscribe to another type with the same md5 doesn't prevent a connection between them. But the actual serialized data are not compatible and will very likely result in a problem at runtime.
well ! where are the module 'em'? I can't find out
It's available as a Debian package: http://packages.ubuntu.com/xenial/python-empy
This bug was first reported in #50 and was marked as wontfix.
As mentioned above as well as in #50 the changing the current behavior implies changing the hash for many messages. This implies that they couldn't be exchange between newer ROS distros (implementing the new behavior) and older ROS distros (using the old behavior). Therefore I will also close this ticket and mark it as "wontfix".