The MASM Forum

Projects => Rarely Used Projects => GoAsm => Topic started by: Yuri on November 27, 2020, 02:45:55 AM

Title: Inaccurate SIZEOF
Post by: Yuri on November 27, 2020, 02:45:55 AM
Code: [Select]
#if x64
    #define PTR DQ
    #define PTR DD


StringArray PTR one, two, three

one     DB "hi",0
one_    DB "hi",0
two     DB "hi",0
three   DB "hi",0


    invoke msvcrt:printf, "%d %d %d", sizeof one, sizeof two, sizeof three
#if !x64
    add esp,16

The output is "6 3 3" instead of "3 3 3". Apparently the size of 'one_' is added to the size of 'one'.
Title: Re: Inaccurate SIZEOF
Post by: wjr on November 28, 2020, 03:32:55 PM
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]
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.
Title: Re: Inaccurate SIZEOF
Post by: Yuri on November 28, 2020, 05:47:22 PM
So it's not a bug and we should simply be careful with forward references? OK, thank you.
Title: Re: Inaccurate SIZEOF
Post by: wjr on November 29, 2020, 07:33:48 AM
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.