Currently DELETing a types_members entry results in all following members of the type shifting. This is unwieldy and unexpected by agent, to the point of giving up when deleting a member in the middle of a 100+ member type and witnessing the outcome. And I fully agree with it since when working in IDA interactively as a human when deleting a member in most cases what you actually mean is Undefine (U shortcut) which preserves the other members offsets by creating a gap instead:
There is even an IDASDK function tinfo_t::del_udm() that does exactly that (instead of https://github.com/allthingsida/idasql/blob/main/src/lib/src/types_members.cpp#L361). This is a semantic change however, needs maintainer decision - will also influence how insert-in-the-middle #47 needs to be implemented (shift the following members or keep them pinned?)
Currently DELETing a
types_membersentry results in all following members of the type shifting. This is unwieldy and unexpected by agent, to the point of giving up when deleting a member in the middle of a 100+ member type and witnessing the outcome. And I fully agree with it since when working in IDA interactively as a human when deleting a member in most cases what you actually mean is Undefine (U shortcut) which preserves the other members offsets by creating a gap instead:There is even an IDASDK function
tinfo_t::del_udm()that does exactly that (instead of https://github.com/allthingsida/idasql/blob/main/src/lib/src/types_members.cpp#L361). This is a semantic change however, needs maintainer decision - will also influence how insert-in-the-middle #47 needs to be implemented (shift the following members or keep them pinned?)