paxcut
commented
2 weeks ago use things like
if ($ + size > sizeof($))
return;or try/catch to stop the evaluation just before the error occurs. Then a single evaluation of the next code to be executed done by hand is enough to tell how error should be fixed. What you are asking for sounds almost like a core dump in a conventional application runtime environment. You could create a separate section to store intermediate values, the patterns placed there won't survive, but the data in the sections is not deleted or reset on errors. Also use std::print() liberally maybe defining a DEBUG macro and #ifdef / #ifndef / #endif.
If a feature like this was ever implemented it will also need the ability to be toggled on and off at will. Keep in mind this type of feature will tend to destabilize ImHex making crashes more frequent so I doubt it will speed up development cycle considering you may lose all the code written so far and may need to start from scratch all over again.
What feature would you like to see?
While developing a pattern for some proprietary file format, I commonly encounter errors like Array grew past set limit or field goes beyond EOF, simply because the pattern is not 100% correct yet.
However, as long as there is a single error, the Pattern Data view remains completely empty. I'd like to have the view filled with all the things that were matched before the error was encountered. Best effort so to say.
An indicator in the Pattern Data view for this best effort approach would be helpful so people don't immediately trust the view in this case.
How will this feature be useful to you and others?
I suspect that this would speed up the development of patterns a lot. I could inspect the Pattern Data view from top to bottom to find the point where the parsed data no longer makes sense, likely being the point where the pattern is not yet correct.
Request Type
Additional context?
No response