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

Runtime crash on erlang when constructing bit arrays #4271

Open
GearsDatapacks opened this issue Feb 20, 2025 · 2 comments
Open

Runtime crash on erlang when constructing bit arrays #4271

GearsDatapacks opened this issue Feb 20, 2025 · 2 comments
Labels
discussion The approach has not yet been decided help wanted Contributions encouraged priority:medium

Comments

@GearsDatapacks
Copy link
Member

Currently, if you run the following code:

pub fn main() {
  let size = 2
  <<2.3:float-size(size)>>
}

The compiler will allow it, but when run, it produces an erlang Badarg error. This is probably not desired behaviour. I'm not sure if we consider this a breaking change, but since it never worked in the first place, I would lean no.

@lpil lpil added help wanted Contributions encouraged priority:medium labels Feb 21, 2025
@lpil
Copy link
Member

lpil commented Feb 21, 2025

I agree, thank you. We need to work out what the right way to handle this would be as we may not be able to statically prevent this.

@lpil lpil added the discussion The approach has not yet been decided label Feb 21, 2025
@richard-viney
Copy link
Contributor

richard-viney commented Feb 23, 2025

Another similar runtime crash related to invalid sizes:

pub fn main() {
  <<<<>>:bits-size(1)>>
}

This also crashes on Erlang with erlang:error(Badarg). On JavaScript it gives a more detailed runtime exception: Error: Invalid bit array slice: start = 0, end = 1, bit size = 0.

The general case can't be statically prevented because the size can be dynamic, but simple cases like the one in the initial description when constructing a float with an invalid constant size could be flagged.

The error on Erlang could be improved if Gleam inserted explicit size checks where relevant.

@lpil lpil removed the bug label Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion The approach has not yet been decided help wanted Contributions encouraged priority:medium
Projects
None yet
Development

No branches or pull requests

3 participants