Open CountBleck opened 6 months ago
Would this perhaps become simpler if we'd keep tracking such segments as MemorySegment
s but allowed the buffer to be null
, indicating all zeroes?
More generally, when not indicating the presence of the segment to Binaryen, we'd always have to assume that memory is zeroed, as the zeroes won't be in the (memory ...)
. Might well be a non-issue in practice, though.
Would this perhaps become simpler[...]?
Oh, that's...a much better idea. Thanks and sorry about that.
Might well be a non-issue in practice, though.
@dcodeIO hmm, would this conflict when --importMemory
is specified without --zeroFilledMemory
?
@HerrCai0907 I changed the commit message; this is technically a breaking change.
@HerrCai0907 I changed the commit message; this is technically a breaking change.
You can modify it when click squash and merge😆 . Actually the message in commit is meaningless.
Fixes #2827.
Changes proposed in this pull request: ⯈ Bump
Compiler#memoryOffset
instead of allocating zero-filled segments.There is an issue with the
initialPages
calculation ininitDefaultMemory
, however. The existing condition to run that calculation depends onmemorySegments.length
, which is now zero if onlymemory.data(n: i32)
is called, as in the memory-config-errors test. Making that calculation occur regardless of the number of memory segments would cause a separate issue: due to the default memory offsets ofoptions.memoryBase
,1024
, or8
, modules that previously compiled with an initial memory of 0 pages would compile with a minimum of 1 page.