cb: Fix uninitialized memory used for equality check #5027
Conversation
Fixed by zeroing the memory. A more "c++ correct" approach may be to add an additional op for equality, and use the "==" operator on the F type in the generate function. But this adds the requirement that F supports equality.
|
My first question is: Is callback class POD? I can see it has user-defined dtor at least. If it is, then memxxx can be used, otherwise it should not (neither to use memcmp as I pinpointed earlier in the |
|
I've created internal ticket to write some more tests for callback. |
|
@0xc0170 The POD restriction on memxxx is for external use. The Callback is aware of its own operations and makes sure not to break their assumptions. The Callback is already handling it's own memory explicitly: @bulislaw agreed, this was just a quick patch so I didn't have time but good idea to track |
There was a problem hiding this comment.
That's the best fix for now however it might be a good thing to precise that comparison operation won't work if the callback class host a Function like object which is not a standard layout type.
Providing a complete, correct solution for all case is a not a trivial task. Indeed, there is no operator== to compare an std::function to another std::function in the standard library.
|
@0xc0170, is this guy viable for 5.6.1? |
|
Probably can't make it, but it could if testing comes back fast enough. /morph test |
Result: ABORTEDYour command has finished executing! Here's what you wrote!
OutputBuild failed! |
|
/morph test |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Fixed by zeroing the uninitialized memory. A more "correct" approach may be to add an additional op for equality, and use the "==" operator on the F type in the generate function. But this adds the requirement that F supports equality.
cc @0xc0170, @pan-
fixes #5017