GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||
GeezerVison is showing github.com — [3.6] bpo-40791: Make compare_digest more constant-time. (GH-23438) by miss-islington · Pull Request #23767 · python/cpython Conversation
|
|
@miss-islington and @benjaminp: Status check is done, and it's a success ✅ . |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@miss-islington and @benjaminp: Status check is done, and it's a success ✅ . |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@miss-islington and @benjaminp: Status check is done, and it's a success ✅ . |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@miss-islington and @benjaminp: Status check is done, and it's a success ✅ . |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Sorry, I can't merge this PR. Reason: |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.