Hi, I would like to complain the commit mentioned by the bot is not the commit I sent out. My patch guarded from access to unallocated memory, while the commit mentioned and attributed to me tests if there are any bits to set/clear and proceeds to use the memory it does not own anyway. Please revert a1ed500836806ef46fc3eafa7ce5f8621938cbc1, I shall come up with a test for the scenario I'm talking about. Best regards, Michał.
On 3 July 2018 at 22:59, Marvin testbot@winehq.org wrote:
Thank you for your contribution to Wine!
This is an automated notification to let you know that your patch has been reviewed and its status set to "Committed".
This means that your patch has been approved, and committed to the main git tree. Congratulations!
Commit: https://source.winehq.org/git/wine.git/commit/ a1ed500836806ef46fc3eafa7ce5f8621938cbc1
Michał Janiszewski janisozaur@gmail.com writes:
Hi, I would like to complain the commit mentioned by the bot is not the commit I sent out. My patch guarded from access to unallocated memory, while the commit mentioned and attributed to me tests if there are any bits to set/clear and proceeds to use the memory it does not own anyway. Please revert a1ed500836806ef46fc3eafa7ce5f8621938cbc1, I shall come up with a test for the scenario I'm talking about.
I believe it does the same thing in a simpler way, but if you have a test demonstrating that it's still broken, please submit it and I'll fix the code.
It looks like your way indeed solves the problem as I am no longer able to observe the issue I saw earlier and I simply have not fully understood the way you rewrote the code. Thanks for cleaning it up then. Michał.
On 4 July 2018 at 09:41, Alexandre Julliard julliard@winehq.org wrote:
Michał Janiszewski janisozaur@gmail.com writes:
Hi, I would like to complain the commit mentioned by the bot is not the
commit I sent out.
My patch guarded from access to unallocated memory, while the commit
mentioned and attributed to me tests if there are any bits to set/clear and proceeds to use the memory it does not own anyway.
Please revert a1ed500836806ef46fc3eafa7ce5f8621938cbc1, I shall come up
with a test for the scenario I'm talking about.
I believe it does the same thing in a simpler way, but if you have a test demonstrating that it's still broken, please submit it and I'll fix the code.
-- Alexandre Julliard julliard@winehq.org
Michał Janiszewski janisozaur@gmail.com writes:
It looks like your way indeed solves the problem as I am no longer able to observe the issue I saw earlier and I simply have not fully understood the way you rewrote the code.
The way it works is that start and count have already been checked against the bitmap size, so we can assume that the mask's high bits won't be set if they wouldn't fit, there's no need to check the size again.
-
Alexandre Julliard -
Michał Janiszewski