Browse Source

Added a bit more integer operation consistency to ByteDataBlock creation (#2272)

This Pull Request fixes a potential overflow when trying to convert a `u64` into a `usize` and then trying to create a byte data block.

Related to this, we seem to be using a `u64` and `i64` as a general approach for an "integer", but ECMAScript doesn't have bounds for them, so they could be as big as infinite. Should we use `u128` and `i128` to have a bigger range?

This would add a performance penalty, though, and we don't have 128-bit platforms usually, so the benefit would probably be minimal, at least when trying to allocate.
pull/2286/head
Iban Eguia 2 years ago
parent
commit
f4d88b7942
  1. 8
      boa_engine/src/builtins/array_buffer/mod.rs

8
boa_engine/src/builtins/array_buffer/mod.rs

@ -748,13 +748,17 @@ impl ArrayBuffer {
pub fn create_byte_data_block(size: u64, context: &mut Context) -> JsResult<Vec<u8>> { pub fn create_byte_data_block(size: u64, context: &mut Context) -> JsResult<Vec<u8>> {
// 1. Let db be a new Data Block value consisting of size bytes. If it is impossible to // 1. Let db be a new Data Block value consisting of size bytes. If it is impossible to
// create such a Data Block, throw a RangeError exception. // create such a Data Block, throw a RangeError exception.
let size = size.try_into().map_err(|e| {
context.construct_range_error(format!("couldn't allocate the data block: {e}"))
})?;
let mut data_block = Vec::new(); let mut data_block = Vec::new();
data_block.try_reserve(size as usize).map_err(|e| { data_block.try_reserve(size).map_err(|e| {
context.construct_range_error(format!("couldn't allocate the data block: {e}")) context.construct_range_error(format!("couldn't allocate the data block: {e}"))
})?; })?;
// 2. Set all of the bytes of db to 0. // 2. Set all of the bytes of db to 0.
data_block.resize(size as usize, 0); data_block.resize(size, 0);
// 3. Return db. // 3. Return db.
Ok(data_block) Ok(data_block)

Loading…
Cancel
Save