[SOLVED] FASM2 error on operand sizes do not match

Index > Main > [SOLVED] FASM2 error on operand sizes do not match

Author

Thread

ctl3d32

Joined: 30 Dec 2009
Posts: 206
Location: Brazil

ctl3d32 22 Mar 2024, 01:21

Greetings,

The code below (mov instruction) compiles in fasm 1, but not in fasm 2.
In fasm 2 it throws the following error: "operand sizes do not match"

How do i fix it?

Code:

...
mov     [sListViewItem + LV_ITEM.iItem],eax

section '.data' data readable writeable
sListViewItem    LV_ITEM   LVIF_TEXT,0,0,0,0,szBuffer3,MAX_PATH,0,0,0
...

Thanks!

Last edited by ctl3d32 on 22 Mar 2024, 11:06; edited 1 time in total

22 Mar 2024, 01:21

rrq

Joined: 17 May 2021
Posts: 2

rrq 22 Mar 2024, 07:16

Put a size qualifier with the operand, as in:

Code:

mov    dword [sListViewItem + LV_ITEM.iItem],eax

22 Mar 2024, 07:16

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 22 Mar 2024, 08:06

The label "sListViewItem" has an associated size (the size of entire structure) and this size takes precedence over the size data of "LV_ITEM.iItem". You can see that if you reverse their order:

Code:

mov     [LV_ITEM.iItem + sListViewItem],eax

But this is not a real fix for the problem, because the expected way of making such kind of access is (and always has been):

Code:

mov     [sListViewItem.iItem],eax

The offset labels were intended to be used in cases like:

Code:

mov     [ebx + LV_ITEM.iItem],eax

where the EBX symbol does not have any specific size associated with it and therefore it's the size of data associated with the offset label that is considered.

In fasm 1 structure labels had no size data associated with them, because there was only a limited set of sizes that you could use - with fasmg this improved. Note that this allows use of constructions like "sizeof sListViewItem".

22 Mar 2024, 08:06

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 22 Mar 2024, 08:38

Tomasz Grysztar wrote:

The label "sListViewItem" has an associated size (the size of entire structure) and this size takes precedence over the size data of "LV_ITEM.iItem".

I think for addressing the smallest item in a set of items should take precedence.

22 Mar 2024, 08:38

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 22 Mar 2024, 08:45

revolution wrote:

Tomasz Grysztar wrote:
The label "sListViewItem" has an associated size (the size of entire structure) and this size takes precedence over the size data of "LV_ITEM.iItem".
I think for addressing the smallest item in a set of items should take precedence.

It's the compatibility with fasm 1 that took precedence here, fasm always applied the first size present in the sum. You get the same kind of error with fasm 1 if your base label has a size.

ctl3d32: You can also get the original code to assemble by modifying the "macro/struct.inc" and removing the size from the main label (it's right at the start of "struct?.instantiate" implementation).

22 Mar 2024, 08:45

ctl3d32

Joined: 30 Dec 2009
Posts: 206
Location: Brazil

ctl3d32 22 Mar 2024, 11:05

Thank you all for the quick response!

Code was fixed by using offset labels as it was inteded to:

Code:

mov     [ebx + LV_ITEM.iItem],eax

22 Mar 2024, 11:05

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum