Closed Leo-Nogismus closed 1 year ago
Hey Jeff, maybe you could have a look at this to see whether this is general enough for you. I had to change quite a bit in the r_exec part but nothing big. I had to think a lot about how to best do this, and this, I think, makes the most sense. If a user-defined class has user-defined operators, we can expect that guards need to be built when seen in the pattern extractor, right?
Thanks!
Looks promising. I'm taking some time off this week, so I can look into the details next week. Is this a blocking issue for you? (In other words, are you able to continue other work such as generalizing CTPX without merging this?) If you need me to study it this week so that you can get other work done, I will.
Oh, I forgot, no, I think I will manage, have a good week!
During initialization, when custom-defined operators are loaded, the opcodes of classes with custom operators are returned and stored in r_exec::Metadata for convenient access. In the pattern extractor, we can now call a function "hasUserDefinedOperators(opcode)" to check whether an object pointed to by an I_PTR has custom-defined operators, thus suggesting that guards need to be built. All objects defined in usr_operators/Operators/operators.h/.cpp can thus be automatically included in the guard building process.