You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
auto rhs = vroom::Location(vroom::Coordinates{10, 11});
I would expect the below to pass
assert(!(lhs == rhs));
but this is not always the case. The comparison code checks presence of index only on left hand side object and assumes the right hand side object to have index as well. This reads to reading from an uninitialised member variable, which is undefined behaviour.
If I flip the arguments
assert(!(rhs == lhs));
the bug is bypassed and result is correct.
The text was updated successfully, but these errors were encountered:
Good catch, I guess this went unnoticed because when parsing json directly we enforce either never or always defining custom index values.
The whole index/coord logic (and hence operator==) for locations is a bit awkward but this is the best I could come up with at the time to handle all possible scenarios. I add to check back to recall why we even need Location::operator==. 😅
This is related to
libvroom
.If I have a location created using an index
and a location created using coordinates
I would expect the below to pass
assert(!(lhs == rhs));
but this is not always the case. The comparison code checks presence of index only on left hand side object and assumes the right hand side object to have index as well. This reads to reading from an uninitialised member variable, which is undefined behaviour.
If I flip the arguments
assert(!(rhs == lhs));
the bug is bypassed and result is correct.
The text was updated successfully, but these errors were encountered: