Author Topic: Inaccurate SIZEOF  (Read 567 times)

Yuri

  • Member
  • **
  • Posts: 179
Inaccurate SIZEOF
« on: November 27, 2020, 02:45:55 AM »
Code: [Select]
#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

  • Member
  • **
  • Posts: 226
    • WJR's website
Re: Inaccurate SIZEOF
« Reply #1 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:
Quote
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.

Yuri

  • Member
  • **
  • Posts: 179
Re: Inaccurate SIZEOF
« Reply #2 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.

wjr

  • Member
  • **
  • Posts: 226
    • WJR's website
Re: Inaccurate SIZEOF
« Reply #3 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.