You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 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.
The text was updated successfully, but these errors were encountered: