You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The sequence_control array theoretically allows up to 255 sequences to exist, but because player_data::scan and module_data::seq_data are allocated as part of their respective structs, the sequence count is limited to 16. This patch raises that limit and moves player_data::scan, the larger of the two scan arrays, to a separate heap allocation.
Large numbers of sequences may be used in games relying on dynamic order changes, which is somewhat common in MegaZeux games (the module I was given, which I'm not sure I'm allowed to share, contains 18). Since the scan doubles as a validity check for module flow, increasing the number of sequences is the easiest way to safely support this.
This should not affect the API at all: xmp_module_info already uses a pointer to an array of an arbitrary number of xmp_sequence structs, and since this array is still allocated as part of the xmp_context, this pointer will never change during the lifetime of any given xmp_context. player_data::scan was never exposed to the API, so (re)allocating it should break nothing.
Merging #382 (69325b4) into master (0122a73) will increase coverage by 0%.
The diff coverage is 76%.
❗ Current head 69325b4 differs from pull request most recent head a5c7387. Consider uploading reports for the commit a5c7387 to get more accurate results
Manual AddressSanitizer (Fedora 34, clang 12) and Visual Studio (x86_64, MSVC 2019) tests passed. (It seems that at some point Fedora and/or clang's MemorySanitizer support for stat() without instrumentation broke, so I don't have a useful result there. The tests get spammed with failures due to struct stat st being "uninitialized" in load.c.)
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AliceLR
force-pushed
the
allow-extra-sequences
branch
from
The
sequence_controlarray theoretically allows up to 255 sequences to exist, but becauseplayer_data::scanandmodule_data::seq_dataare allocated as part of their respective structs, the sequence count is limited to 16. This patch raises that limit and movesplayer_data::scan, the larger of the two scan arrays, to a separate heap allocation.Large numbers of sequences may be used in games relying on dynamic order changes, which is somewhat common in MegaZeux games (the module I was given, which I'm not sure I'm allowed to share, contains 18). Since the scan doubles as a validity check for module flow, increasing the number of sequences is the easiest way to safely support this.
This should not affect the API at all:
xmp_module_infoalready uses a pointer to an array of an arbitrary number ofxmp_sequencestructs, and since this array is still allocated as part of thexmp_context, this pointer will never change during the lifetime of any givenxmp_context.player_data::scanwas never exposed to the API, so (re)allocating it should break nothing.