[Bug] NullablePtr inside namespace crashes editor upon invalid member type in pointed struct

[dakrk]

Operating System

Linux

What's the issue you encountered?

When a std::ptr::NullablePtr that's inside a namespace which is pointing to a struct that's also inside the same namespace has one of its members using an invalid type, ImHex will crash. The script doesn't even have to be evaluated, since merely typing in the pattern editor can cause it to trash.

How can the issue be reproduced?

1. Open ImHex
2. Open or create file
3. Paste the following pattern into the pattern editor:

   
   import std.ptr;

namespace a { struct b { INVALIDTYPE c; };

struct d {
    std::ptr::NullablePtr<b, u32> e;
};

}

4. ImHex should immediately crash after pasting, when the desired result should be having it be pasted without crashing.

### ImHex Version

1.33.2

### ImHex Build Type

- [X] Nightly or built from sources

### Installation type

Manual

### Additional context?

This is not an issue with my own builds, as I have successfully reproduced the issue using the Windows binaries provided on the release page.

[paxcut]

I tried this on windows on an slightly old master (1.33.0) and I can't reproduce it. Not only it doesn't crash but upon evaluation it correctly identifies the problem.

[dakrk]

Hmm, this must've been first introduced during 1.33.0's development then, as the Windows release build of it also has the issue.

(At least given the commit your build was on, it should be easier to track the time frame of when this issue was introduced.)

[paxcut]

[paxcut]

I just tried the latest master (1.33.0) and it is also not reproducing the error. In spite of the numbering, release branch builds (1.33.1, 1.33.2,...) are not as recent as master branch builds (1.33.0) and may not contain the latest fixes. To test the latest code use always the master branch builds (they end in zero). You say you tested latest master build (1.33.0 build 2 days ago) on windows and saw the error?

[dakrk]

Right, no, all of my testing has been on release builds (so the stuff you see on the GitHub releases page, and are built on commits such as 8802a8e).

[paxcut]

that was built on March 23 and should be considered ancient. To test bugs for relevancy use nightlies which can be obtained from either the main github page (at the readme very top) or from werwolv.net at the very bottom.

[dakrk]

I see. In that case this issue seems to have already been fixed (presumably for a long time), as I cannot reproduce it with the latest nightly build. Sorry.

[paxcut]

Nothing to be sorry about. The time you took to report and follow up on the issue is much appreciated regardless of the issue's outcome. Also thank you for closing the issue. Issues can only be closed by the author or by the repository's owners so resolved issues remain open which in turn is perceived as if the issue still exists by those who are browsing it.