dMZX Forums: Setting $str.length never sets the string's length to the value you attempt to set it to -> Archived MegaZeux Bugs -> Tracker

set "$str" to "Hello world!"
set "LOCAL" "$str.length"
set "$str.length" to 12
* "LOCAL: &LOCAL&  Str length: &$str.length&"

LOCAL is properly set to the length of the string, 12, but after setting $str.length to anything else, $str.length will actually be set to the next highest power of 2 if it is equal to the current string length or greater. If it is smaller, it returns the value you've just tried to set it to plus 1. Will edit once I've had a chance to check the GIT.

Updating status to: Confirmed
Updating version to: GIT
Updating Introduced In Version to: 2.82b

MegaZeux has behaved this way since version 2.82b, when setting $str.length was added. Prior to this, "$str.length" in a set command would be interpretted as "$str.0". This behavior persists into the latest GIT. Notably, the help file says that setting $str.length will "will now truncate or enlarge the string to the size specified", and while decreasing $str.length does truncate the string, it fails to set the length to the correct value, so this can definitely be classified as misbehavior from a user perspective in both cases.

Updating status to: Proposed Fix
Updating version to: GIT

Issue fixed in: 2.84

/* As a kind of unnecessary optimisation, if the string already exists
 * and we're asking to extend its length, increase the length by a power
 * ( of two rather than just by the amount necessary.
 */

Yeeaaaaaaaaaahhhhhhh except that's not really what the user should ever expect or want, and it was publicly advertised as setting the length to what the user told it to be. I get what was trying to be done here, would having a separate attribute keeping track of how big the allocated space is hurt performance/memory much?

The proposed fix is version locked to prevent any 2.82b to 2.83 worlds from misbehaving if they had relied on this, and is available in my fork.

Updating severity to: 3 - Medium

I have an alternate fix proposal that possibly makes the most sense. Since force_string_length only allocates the string and wipes the newly allocated space, the 2^x value could be passed there and then the length setting code could simply make sure to set the length attribute to the given value.

Updating status to: Fixed
Updating version to: 2.83


Any further changes to the string allocation will have to wait for the next version.

Moving to: Archived MegaZeux Bugs