| commit | 87f92004381c80cea347dc339f8275ea46fa76de | |
| author | rofl0r <rofl0r@users.noreply.github.com> | |
| Fri, 10 Jan 2020 22:08:56 +0000 (10 22:08 +0000) | ||
| committer | rofl0r <rofl0r@users.noreply.github.com> | |
| Fri, 10 Jan 2020 22:08:59 +0000 (10 22:08 +0000) | ||
| tree | d612e860c193109bf0b32b6a9c9d23b67c198b82 | treesnapshot (tar.gz zip) |
| parent | 48ce54dd26cfe8f5a633e1fcdc46dd054651b75a | commitdiff |
Clib32: preliminary support for new v30 datafile format
the file format was introduced to be able to deal with files > 2GB,
but we currently re-use the 32bit length/offset fields in the
multifile struct, so we can't deal yet with files/offsets > 4GB.
processing such a file will raise an assert error.
apparently the new format also removes some restrictions on number
of contained files and filename lengths, so this may also be something
to revisit.
also, the code to detect v30 format from file-end signature is currently
lacking.
this was implemented in upstream ags in ab7486dac6f4c6fb86c35df8f630b3926a7c540b
the file format was introduced to be able to deal with files > 2GB,
but we currently re-use the 32bit length/offset fields in the
multifile struct, so we can't deal yet with files/offsets > 4GB.
processing such a file will raise an assert error.
apparently the new format also removes some restrictions on number
of contained files and filename lengths, so this may also be something
to revisit.
also, the code to detect v30 format from file-end signature is currently
lacking.
this was implemented in upstream ags in ab7486dac6f4c6fb86c35df8f630b3926a7c540b
| Clib32.c | diffblobblamehistory |