-
Notifications
You must be signed in to change notification settings - Fork 1
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
continuePlaying() reads beyond numbers at end of string #1
Comments
What is the cause of this? Is this just using the stack and not calculating and allocating memory? Just curious before I start looking, I need this fixed. and null termination doesn't seem to be working reliably for me. |
I haven't debugged this yet. It's probably just a bug in the section that converts the number part from the string. Have you tried the alternative notation that I mentioned (see issue). What you could also try is adding some spaces. |
I am having better luck now, not sure what changed, I will just use a wrapper for now and null terminate and see if it happens again. Thanks, I did a quick look , and the code was a bit more that my knowledge of mml atm, so I could not really trace it. |
Good to read you have some success. I don't know when, but if I found time to debug and fix this, I will publish the new version here on GitHub and update this issue. Another issue I would like to improve is multi-channel synchronization, but that isn't as easy and digging into that rabbit hole will take some more time. You can follow to be notified of updates. |
getNumber() returned without rewind when end of string, causing subsequent getChar() to miss the end of string terminator \0
Fixed in commit b2e7d2a |
When ending the play-string with a number (eg. "T120 O4 G16") the parser may read beyond the end of the string and play whatever is next in memory. That could be another play-string which is then also played, but it could also be something else.
Workaround: use alternative notation (eg. "T120 O4 L16 G") or an addional terminator (eg. "T120 O4 G16\0").
The text was updated successfully, but these errors were encountered: