Author Topic: internal defines bug fix  (Read 2687 times)

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
internal defines bug fix
« on: February 01, 2014, 11:29:37 PM »
Today I uncovered a pesky little bug while trying to get the gtk demo to compile in preparation for our next release.  To make a long story short - when defining structures NASMX creates a few defines per struc member in order to ensure that we get the correct type and offset of the member.

The bug manifested itself as follows:
Code: [Select]
NASMX_STRUC GActionInterface
NASMX_RESERVE g_iface, int8_t, GTypeInterface_size
NASMX_RESERVE get_name, uint32_t, 1
NASMX_RESERVE get_parameter_type, uint32_t, 1
NASMX_RESERVE get_state_type, uint32_t, 1
NASMX_RESERVE get_state_hint, uint32_t, 1
NASMX_RESERVE get_enabled, uint32_t, 1
NASMX_RESERVE get_state, uint32_t, 1
NASMX_RESERVE set_state, uint32_t, 1
NASMX_RESERVE activate, uint32_t, 1
NASMX_ENDSTRUC

As the NASMX_RESERVE macro parses each member we previously would simply append "_type" to the member name and create a new define for internal book-keeping.  Then the member name itself gets EQUated to the offset of that member in the structure.  The issue was that, when we attempted to parse the "get_state" member, the previous member named "get_state_type" was already equated!  Subsequently, the definition of the structure itself would fail causing an assembler error.

This has been corrected in the latest snapshot.  However, and unfortunately, we cannot change the "member_name" %+ _size equates.  Subsequently, two identically named structure members ( but with one member having _size at the end of the name ) will still cause issues.  This is the legacy of backward compatibility.

Offline encryptor256

  • Full Member
  • **
  • Posts: 250
  • Country: lv
  • Win64 .
    • On Youtube: encryptor256
Re: internal defines bug fix
« Reply #1 on: February 10, 2014, 06:53:23 PM »

This bug fix mostly affect those, who use, this kind'a variable definition rules, like "get '_' name" : "get_name".

For me it's pretty rare, never existent.

I usually define like this - "getName", (First word in lower case, other words with capital letter),
or "GetName",
or my recent usage in assembly, would result in "get.name", (This, dot usage, might cause problems, if used in C\C++),
or my recent-recent usage in assembly, would result in "getname", (All in lower case and only letters).

If it's a pointer to function: ptrgetname, ptrGetName, PTRGetName.



Encryptor256's Investigation \ Research Department.