* Make cfread_string_len read no more than fits in the buffer
The char* version only checked the stored length with an Assertion, so in
release builds a string longer than the buffer was read past its end, and a
negative length wrote before it. It now reads at most buffer_size - 1
characters, skips the rest so the next read stays aligned, always terminates
the buffer, and logs when characters are dropped.
The SCP_string version clamps a negative or past-the-end length to what the
file still holds, so a corrupt length can't cause a huge allocation.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* Warn when cfread_string_len cuts or rejects a string
The char* version now reads up to the full buffer, so a string that fills it
exactly without a terminator is caught rather than cut silently. Both versions
clamp the stored length to what the file still holds and check the read limit
before reading, since cfseek does not; inside a limited pilot section a corrupt
length, negative or too long, throws cfile::max_read_length so the loader can
drop the section. A cut string, a corrupt length or a failed read gets a
Warning, and a failed read no longer leaves the file position off by the bytes
it did read. A buffer size of 0 skips the string without writing to the buffer.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* Write the cfread_string_len warnings inline with format arguments
* Share one core between the cfread_string_len overloads
Both overloads now read the length, work out what is stored, read the
body and warn through the same three steps. A length that does not fit
the file throws inside a limited section even when the section ends at
the end of the file, a zero-size buffer still warns about a corrupt
length, and a cut-off length field warns (or throws inside a limited
section) instead of reading as an empty string.
* Share cfread's read-size check with cfread_string_len
The string reader had its own copy of the read-limit check, without the
clamp to end-of-file that cfread does first, so a truncated last section
threw where it used to load. Both now call cf_check_read_size. A negative
length still throws inside a limited section, a cut-off length field only
warns, the cut warning counts bytes, and the helpers sit in an anonymous
namespace.
* Keep cfread_string_len quiet at a clean end of file
A string read at a clean end of file now returns an empty string without a
warning, as cfread_int does; a length field cut partway still warns, so a
truncated pilot list no longer raises one warning per remaining entry. A
zero-size buffer warns when it drops a string, and an invalid file reads as an
empty string again. Adds tests for an empty string inside a limited section,
the one-short boundary, a length still past the limit after the clamp, a
length field cut by the limit, the string returned after a failed read, and
cfread at end of file.
* Warn when a length field is missing before the end of a file
A failed length read now counts as a clean end of file only when cfeof says
so, so a file whose recorded size is larger than its data still warns. Tests
now pin the read-limit check after the end-of-file clamp, cfread at the end of
file past the limit, a length field cut short on disk, the zero-buffer
Assertion in Debug, and an empty string into a zero-size buffer.
* Close the test file before removing it in the cfile temp-file guards
Windows cannot delete an open file, and a failed ASSERT returns with the
file still open, so the guard now closes it first.
---------
Co-authored-by: Dustinspace217 <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
FSO doesn't appear to use this any longer. And even when it was enabled the
requirements made it largely useless anyway. Removing to clean up cfile a
bit and so we don't have to keep maintaining it.
LZ4 moved to lib folder and added cmakelists.
Added several position check to match cfilearchive ones for compressed files.
Changed header check to int.
Moved the compression functions to separated files, added dynamic blocksize support for LZ4 and a decoder buffer to make sure every block is only read from file and decoded only once.
I just dumped everything into cfilearchive to avoid a fight with the includes that i cant win for now.
It dosent work, DDS utils complains about DDS filecode.
The only thing a CFILE contained was a version field which isn't used
anymore so that could be removed which basically meant that CFILE was
just an indirection to a Cfile_block which I then just renamed to CFILE.
The CFILE type is an opaque handle now since the contents are not
relevant to a user of Cfile.
This allows to use more complex file structures in the executable
without requiring that those exist as real files. The rest of the code
does not need to handle the difference between a default file and a real
file anymore which means that it's now possible to embed image files
into the executable since bmpman only needs to use the standard CFile
API.
I added two tests which check if the default file can be found and
opened and if a mod file overrides the default file which should always
be possible.
Invalid values previously corrupted the internal position counter which
caused crashes on some platforms because the position counter would
overflow in the next read operation. I added some assertions to track
the position counter corruption and it's probably a good idea to leave
them in to catch possible future errors early.
The actual fix was to just ensure that the seek position it always valid
for the file.
This fixes#1059.
- Add On Mission Start, On Mission End hooks; swap Warpin and Warpout to Warp In and Warp Out
- Safer handle helper structs
- Improved math, eg matrix interpolation and vector multiply/divide
- Filesystem read AND write support
- Initial scripting orders support
- Better waypoints support
- Assorted requested scripting functions
bmpman:
- Safer bm_get_filename
cfile:
- Support for RW, rather than just R or W, file modes.
model:
- Safer texture_info struct. Taylor, I know we talked about this, but I realized that it was just a lot better for what it does and it shouldn't be too much trouble to replace with the new system (operations tend to be much more concise and clear). Let me know if any unexpected difficulties arise.
