Precisely what the title says.
Numbered Steps to Reproduce Problem:
1. Create a datum that is not an atom, image, or client.
2. Pass its vars list to external code.
In external code:
3. Return the length of the passed in list.
Back in DM:
4. Compare the return value with
length(thing.vars)
or thing.vars.len
.Code Snippet (if applicable) to Reproduce Problem:
C++ code:
extern "C" BYOND_EXPORT CByondValue bug_case(int n, CByondValue v[]) {
CByondValue result;
if (n < 1 || !Byond_Length(&v[0], &result)) {
ByondValue_Clear(&result);
}
return result;
}
BYOND code:
var/datum/test_datum = new/datum()
var/external_length = call_ext(LIB, "byond:bug_case")(test_datum.vars)
if(isnull(external_length))
world.log << "Byond_ToString returned false"
else
world.log << "[external_length] [test_datum.vars.len]"
Expected Results:
A string with two of the same number should be output.
Actual Results:
The first number in the output string is 0, while the second is not 0.
Does the problem occur:
Every time? Or how often?
Every time
In other games?
I got this bug to happen both on tgstation code and in a test project.
On other computers?
Untested
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
The 515 changelog makes no references to changes to the behavior of
Byond_Length
. As such, I believe this is not a regression.Workarounds:
Code that needs to know the length of a list can be informed in advance if a non-atom vars list is being passed to it, and be passed its precalculated length from dm. This, needless to say, is extremely impractical.