Repo instructions from @Tutez64:

take the SWF file from PR 44 or 45 repro and you'll see PR 40 fixes errors happening while exporting it. Following tests won't succeed due to the lack of changes from 44/45 but that's not related to 40 anyway

I can reproduce the Eof exception with the sample projects attached to PRs #44 and #45. I confirm that it is fixed after applying commit 385725a.

However, it doesn't seem to make any difference with those projects whether I include or omit commit c40ec6c. Can you include a project where at least one null exception reproduces without the changes in commit c40ec6c? Thanks!

#44 only needs the EOF fix, and #45 does need both, but it appears that for the second one to show its usefulness, you also need to also include #45 changes, which isn't ideal.
I suggest you use the repro from #46 instead, it shows Error: Invalid field access : classes when using the master branch, and c40ec6c (the change in FrameScriptParser.findClassByName) fixes it. Other changes in FrameScriptParser aren't needed for my use case, they are here to potentially avoid similar issues, but if you want to revert them it is fine for me.
Sorry for the inconvenience, let me know if you require anything else!

Okay, thanks. I can reproduce where findClassByName is encountering null abcData.

However, I noticed that when I try to load your SWFs in Flash Player, it is throwing a VerifyError because the referenced classes don't exist. This makes me suspect that the reason that there is no null check for abcData there is because it is actually required by the SWF spec. That makes me wary to merge that part of the PR. Do we really want to support invalid SWFs? Or am I misunderstanding, and official Adobe/Macromedia tools might actually create a SymbolClass tag that references a class that isn't in the ABC data?

Additionally, I'm having trouble finding one of your sample projects that triggers any of the parts of this PR where you added this code:

else if (#if (haxe_ver >= 4.2) Std.isOfType #else Std.is #end (tag, TagExportAssets))
{
	for (symbol in cast(tag, TagExportAssets).symbols)
	{
		processSymbol(symbol);
		symbolsByTagID.set(symbol.tagId, symbol);
	}
}

That's weird, I don't have any error when opening env_a.swf in Flash Player.
In my real game project, AIR has no issue using a SWF file who doesn't have an abcData, but this file was causing Error: Invalid field access : classes here.
This is also the same file that required the addition of TagExportAssets. Without it, the exported library would be empty. JPEXS makes it easy to see why:
Other files:

This file:

I made a stripped down version: assets.zip

I just noticed something about FrameScriptParser, as I said previously the change in findClassByName is all I need, but if instead of keeping this change, I keep the other three changes together, it works too. I don't think it would hurt to keep all 4 of them, but you have these two other options available.

In Flash Player 32.0.465 (the standalone content debugger) on macOS, I see the following errors reported when I open env_a.swf by double-clicking on it:

• ReferenceError: Error #1065: Variable NavCollisionRectangle is not defined.
• ReferenceError: Error #1065: Variable PropA is not defined.
• ReferenceError: Error #1065: Variable SharedButton is not defined.
• ReferenceError: Error #1065: Variable SharedBitmap is not defined.
• ReferenceError: Error #1065: Variable BitmapHolderA is not defined.
• ReferenceError: Error #1065: Variable SharedClip is not defined.

I thought that I remembered seeing VerifyError instead of ReferenceError yesterday, but I guess I was mistaken. Or maybe the Linux Flash Player behaves a little differently. I'm testing on macOS this morning.

Regardless, these are the same class names in env_a.xml added to the SymbolClassTag.

None of the .xml files for the asset SWFs seem to define an ExportAssets tag. Although I am not familiar enough with ffdec's XML format, and it's possible that I'm misunderstanding exactly where that tag should come from.

When I open your new assets.swf in Flash Player, I do not see any exceptions, so that's promising. I'll dive in a little more to see if I can use this one for testing.

Merged as c1bd371 and 12b8b4d. Just some minor tweaks, and some comments why abcData might be null.

I was able to work with your new stripped down assets.swf. As I mentioned, Flash Player does not throw the same ReferenceError as with the other SWFs that used TagSymbolClass instead of TagExportAssets. I confirm that the TagExportAssets path is triggered for the new assets.swf, and the check for null abcData makes sense to me in that context. The symbol has a name, but it is not a class name, so it seems like abcData should not be strictly required.