Inaccurate SIZEOF

[Yuri]

Code Select Expand


#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'.

[wjr]

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:

Since 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:

Code Select Expand

StringArray PTR one, one_, two, three
or the better alternative with StringArray defined after the one to three declarations so that those symbols would not initially be forward references.

[Yuri]

So it's not a bug and we should simply be careful with forward references? OK, thank you.

[wjr]

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.