Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix unsafe code generation for binary matching #9341

Merged

Conversation

bjorng
Copy link
Contributor

@bjorng bjorng commented Jan 23, 2025

No description provided.

@bjorng bjorng added team:VM Assigned to OTP team VM fix labels Jan 23, 2025
@bjorng bjorng self-assigned this Jan 23, 2025
Copy link
Contributor

github-actions bot commented Jan 23, 2025

CT Test Results

    2 files    332 suites   9m 26s ⏱️
  838 tests   836 ✅ 2 💤 0 ❌
5 585 runs  5 583 ✅ 2 💤 0 ❌

Results for commit 0d454bd.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

// Erlang/OTP Github Action Bot

@bjorng bjorng added the testing currently being tested, tag is used by OTP internal CI label Jan 23, 2025
@bjorng bjorng linked an issue Jan 23, 2025 that may be closed by this pull request
jhogberg and others added 2 commits January 24, 2025 14:07
The internal instructions `bs_checked_get` and `bs_checked_skip` have
confusing names. One might think that they do some extra checking,
while the opposite is true.

Rename them to `bs_ensured_get` and `bs_ensured_skip` to make the
connection to the `bs_ensure` instruction clearer.
@bjorng bjorng force-pushed the bjorn/compiler/bs_match/GH-9304/OTP-19448 branch 2 times, most recently from 2b15577 to 822eeb6 Compare January 24, 2025 13:13
The compiler could sometimes generate unsafe code when
matching literal data in a binary. For example:

    t(Data) ->
        <<Rest/bits>> = Data,
        {_, Bits} = ext:ernal(Rest),
        case Rest of
            <<0, _:Bits>> -> not_empty;
            <<>> -> empty
        end.

The generated code for the first clause of the `case` would
look like this:

    {bs_match,{f,20},{y,2},{commands,[{'=:=',nil,8,0}]}}.

That is unsafe because the first command in a `bs_match` instruction
must always be an `ensure*` instruction to ensure that the bitstring
is of sufficient size.

This unsafe code generation was introduced in 60f8f9e.

This commit ensures that a `bs_match_string` instruction will be
emitted instead of a `bs_match` instruction:

    {test,bs_match_string,{f,20},[{y,2},8,{string,<<0>>}]}.

Fixes erlang#9304
@bjorng bjorng force-pushed the bjorn/compiler/bs_match/GH-9304/OTP-19448 branch 2 times, most recently from 83e28fe to 0d454bd Compare January 24, 2025 14:28
@bjorng bjorng requested review from jhogberg and lucioleKi January 28, 2025 12:22
@bjorng bjorng merged commit 47c1a91 into erlang:master Jan 29, 2025
24 checks passed
@bjorng bjorng deleted the bjorn/compiler/bs_match/GH-9304/OTP-19448 branch January 29, 2025 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix team:VM Assigned to OTP team VM testing currently being tested, tag is used by OTP internal CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Weird case clause using OTP master with binary data from a NIF
3 participants