asar
asar copied to clipboard
`datasize` doesn't work on zero-length data
asar 1.90
arch spc700
norom
org 0
Data:
db ""
DataEnd:
print dec(datasize(Data))
This prints:
test.asm:10: warning: (Wdatasize_last_label): Datasize used on last detected label 'Data'. [print dec(datasize(Data))]
test.asm:10: warning: (Wdatasize_exceeds_size): Datasize exceeds 0xFFFF for label 'Data'. [print dec(datasize(Data))]
16777215
Alternatively:
asar 1.90
arch spc700
norom
org 0
Data:
db ""
DataEnd:
db $00
Foo:
print dec(datasize(Data))
This prints 1, using Foo as the next label.
The way I see it, this can be fixed by having snes_label also record the position in the source file where the label is defined, and using that to find the next label. But this is a complete change in behaviour, as datasize currently only cares about whatever label points to the closest further (but not same) position in the output binary. Therefore, I don't think this fix is possible without potentially breaking existing code.
Side-note: I humbly believe that Wdatasize_last_label ought to be an error instead of a warning. Also note that, unless the label argument sits in bank $FF, the second warning will always be thrown, even though it makes no sense here.
we implemented your suggested fix in asar 2.0, imo that behavior makes way more sense anyways
I just thought of an interesting unhandled edge-case: what if there's an org or base statement between the datasize'd label and the next? Or, perhaps more simply/relevantly put, what if the next label has a lower pos? Is that a worthy condition to error-guard? Maybe you'd want to disallow org and/or base between the labels altogether?
there's already the warning for "datasize exceeds 0xffff", i don't think this should be handled any different. (though there's also the "datasize on last label" warning, i agree that that one really should be promoted to error.)
The message "datasize exceeds 0xFFFF" isn't exactly accurate or helpful in the negative case though.