Unmatched malloc/free in `emulator_delete` about binjgb HOT 6 CLOSED

I see. I'm ok with that.

from binjgb.

It's a bit weird I suppose, but the way it currently works is that the ROM data ownership is passed to the emulator. Are you using this in some way where you want to retain ownership of the ROM data after the emulator is destroyed?

from binjgb.

The application layer is written in C++. The emulator per se and the ROM are both retained by a wrapper class. In particular the ROM data is created and owned as a member field like std::shared_ptr<Bytes> rom = std::shared_ptr<Bytes>(new Bytes(...)). They will be both unused and released at a same time; so the problem is not a ROM lives longer than an emulator instance, it is just I hope that ROM is released consistently with it's creating.

from binjgb.

Unfortunately that's not a valid strategy with the most recent changes, since the emulator may resize the rom data (see e.g.

from binjgb.

Ok. Then I think it's better if there were another initialization workflow that duplicates input ROM data inside emulator. In short, an emulator who is in charge of freeing should be also in charge of allocating the space for ROM data.

from binjgb.

At least for the ways I use emulator_new(), it works best to pass ownership. The calling code has no need for the ROM data after it's been loaded. And similarly, it doesn't make sense for the emulator itself to allocate the space since it doesn't know how much it will need; the ROM data could be coming from a file on disk, or generated automatically in memory, or anywhere else.

If you want your calling code to retain ownership the best way is to make a copy yourself to give to the emulator, rather than having an additional option in EmulatorInit to do this.

from binjgb.