Cascading Structures

[Laocoon]

So I guess I only play around with this stuff once every couple of years...

I have seen several examples of structures inside of structures. Most of them repeat defining the structure inside. This includes the official example on how to use structures as well as the use inside 'Windows.inc'. Sure I can do that. But is there any reason the following wouldn't work (besides just not working)?

Code: [Select]

NASMX_STRUC POINT
 NASMX_RESERVE x, uint32_t, 1
 NASMX_RESERVE y, uint32_t, 1
NASMX_ENDSTRUC

NASMX_STRUC RECT
 NASMX_RESERVE TopLeft, POINT, 1
 NASMX_RESERVE BottomRight, POINT, 1
NASMX_ENDSTRUC

Reasonings behind this simpler way include being able to change the structure in just one place and update the rest of your sources. Say in building server/client applications.

Code: [Select]

;// Protocol.inc
...
NASMX_STRUC PROTOCOL
 NASMX_RESERVE action, uint32_t, 1
 NASMX_RESERVE id, uint32_t, 1
NASMX_ENDSTRUC
...

;// Server.asm
...
%include 'Protocol.inc'
...
NASMX_STRUC Server
 NASMX_RESERVE ServerId, uint32_t, 1
 NASMX_RESERVE Protocol, PROTOCOL, 1
 NASMX_RESERVE reserved1, uint32_t, 1
NASMX_ENDSTRUC
...

;// Client.asm
...
%include 'Protocol.inc'
...
NASMX_STRUC Client
 NASMX_RESERVE ClientId, uint32_t, 1
 NASMX_RESERVE Protocol, PROTOCOL, 1
 NASMX_RESERVE reserved1, uint32_t, 1
NASMX_ENDSTRUC
...


Above you would only have to Change PROTOCOL in Protocol.inc to affect both Server.asm and Client.asm.

At this point, if you wanted to add "NASMX_RESERVE Length, uint32_t, 1" to PROTOCOL, you have to change it 3 different times. Perhaps I just haven't found the easy way of doing this?

EDIT: Or perhaps I've been up too late to ask the real question....

Code: [Select]

NASMX_STRUC XXXX
 NASMX_RESERVE Name, NASMX_TCHAR, 254
NASMX_ENDSTRUC

NASMX_STRUC YYYY
 NASMX_RESERVE x, XXXX, 1
NASMX_ENDSTRUC

...
proc SetName, ptrdiff_t y
...
 mov __DI, ptrdiff_t [argv(.y)]
 add __DI, YYYY.x.Name ;//Error here "symbol 'YYYY.x.Name' undefined"
...

The only fix I've found is to embed NASMX_STRUC x, XXXX inside of YYYY thus making 2 copies of the structure to maintain.

[Rob Neff]

The short answer is: You must repeat the nested structure definition within the outer structure definition.

The long answer is:
It took nasm's preproccessor a while to get to the point where we could build an advanced and reliable framework solely out of macros.  If my memory serves me right - when nested structure definitions were introduced we didn't have recursive macro capability.  I tried doing something similar using nasm's context feature to simulate that but I recall not getting very far.  I think it wasn't until the 2.11 release where the preprocessor really worked the way it should (or at least the way I thought it should).

To allow you to define only the structure name within a structure requires us to maintain each structure definition completely in memory in order to automate all member offset equates for future structure definitions.  Nasm itself does this somewhat and in retrospect it seemed a rather heavy burden to place on a macro system.  I've advocated that this feature truly belongs in Nasm itself - see http://forum.nasm.us/index.php?topic=872.0.

Finally, after releasing NASMX 1.4 I was kinda burned out and haven't felt the urge, or saw a need, to make any further improvements since.  If you, or anyone reading this, would like to enhance the struct/union definitions I might be willing to merge it in if it's not too heavy.  However, personally, I'd rather you spend the time, if you have it ( I don't ), on the nasm side of things and submit a patch to the main developers since that's where I feel it belongs in the first place.

[Laocoon]

I appreciate all the work that you have done. I wish I had the time to work on it myself.

It's also nice to see a response in an otherwise dead forum.

Maybe I'll mess around with it a bit. I was thinking a workaround using %include might be possible and putting each structure in it's own .struc file. Obviously not the best way but it may work for me in my situation...