#if x64
#define PTR DQ
#else
#define PTR DD
#endif
.CONST
StringArray PTR one, two, three
one DB "hi",0
one_ DB "hi",0
two DB "hi",0
three DB "hi",0
.CODE
Start:
invoke msvcrt:printf, "%d %d %d", sizeof one, sizeof two, sizeof three
#if !x64
add esp,16
#endif
ret
The output is "6 3 3" instead of "3 3 3". Apparently the size of 'one_' is added to the size of 'one'.
Correct about the incorrectness. Interesting and unfortunately apparently not as simple as 1 2 3. In this case it looks like I may need to further refine the help file:
QuoteSince GoAsm is a one-pass assembler, SIZEOF only returns the proper value for a label which starts and ends earlier in the source script
along with the another descriptive sentence of the SIZEOF method that follows shortly after. GoAsm does give an error message for
SIZEOF Label where
Label gets defined later (even if used earlier as a forward reference). In this particular case something improper can get returned due to forward references. This wouldn't be the case if
one_ wasn't defined near there, or the following was used instead:
StringArray PTR one, one_, two, threeor the better alternative with
StringArray defined after the
one to
three declarations so that those symbols would not initially be forward references.
So it's not a bug and we should simply be careful with forward references? OK, thank you.
Not good to have such an inaccuracy, so still reviewing the situation, but that would be my first-pass assessment - be careful with SIZEOF a forward reference. Actually, GoAsm does fine with forward references, and generally does so even in combination with SIZEOF, but this particular instance had a less common 'nonsequential' mixed usage of labels and forward references with an undesirable consequence. Nice find though, surfacing after about two decades, thanks... so now more of a known issue with the SIZEOF method.
Generally more efficient assembly under the hood with a one-pass assembler if you can avoid forward references.