Validate AtomicFixnum update results before mutation - #1114
Conversation
bensheldon
left a comment
bensheldon
left a comment
There was a problem hiding this comment.
How would it become corrupted? Can it be tested?
|
The invalid block result replaces the stored integer in the mutex implementation; the C implementation likewise passed the arbitrary Ruby VALUE through compare-and-set without enforcing the numeric invariant. Later numeric operations then operate on a non-integer value. I added a shared regression example that returns a String, verifies the update raises, and verifies the previous integer remains intact. It runs against both MutexAtomicFixnum and CAtomicFixnum; after compiling the extension, the focused suite passes with 59 examples and 0 failures. |
| expect { | ||
| atomic.update { 'not an integer' } | ||
| }.to(raise_error { |error| | ||
| expect(error.class).to be(ArgumentError).or(be(TypeError)) |
There was a problem hiding this comment.
Can you be specific here? Why would it be 2 different kinds of error?
2 participants
Validates the block result through the same integer assignment path before changing state. Invalid update results now raise without corrupting the mutex-backed or native atomic value.
Verified by focused native/mutex specs and models; the review composite passes 2,796 examples with no failures.