Open AnakinRaW opened 1 year ago
IIRC all formats use unsigned integers for index tables and the like but I'm not sure just how likely it is to even have more than int32.Max entries. For a first usable version I think it should be fine as long as the overflow is handled properly.
This would also mean feature parity with the currently released libraries so those can be replaced with a release relatively soon and a future update could then add the unsigned support if necessary.
the current implementations (for MEG) only accept int32 type. and negative values throw an exceptions.
Since the public models/interfaces do not expose these kind of access anyway, this is an implementation details which could be changed anytime.
Idk for .alo files where it might be more usual to acutally use uint values.
The DAT refactoring I did should be in line with any MEG changes in that regard, so for those formats we should be good for the time being.
Adding to your concern, chunk-files in general could be an issue, maybe @andrewfullard or @inertials-revenge have a better grasp of how large chunked file indexes etc. can grow?
In .NET we have the problem that lists can only be indexed by int32 values. Many alamo models, or at least MEG, allow uint table indexes.
Currently we limit our model implementations to only allow int32.
I already implemented a UnsignedList which should be able to solve the problem, but i'm not sure whether we should use it or not. At least for MEG i think we can be 100% sure we never get an archive with int32.Max + 1 files.