Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: portej05 on July 29, 2009, 09:54:46 pm

Title: The deal with safe_strings
Post by: portej05 on July 29, 2009, 09:54:46 pm
Hi all,

Recently there was a large commit to the FSO codebase that has been titled 'safe_strings'.
This commit implements some of  ISO/IEC 9899:1999 TC2, ISO/IEC TR 24731 (http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf), particularly strcpy_s and strcat_s (others will come as they get added).

We're already starting to receive reports of various assertions being caused by safe_strings.
Let me be clear about this - safe_strings is now considered stable - if you get a warning from safe_strings, there IS a buffer overrun. safe_strings will not warn you whether or not you're going to corrupt your stack (for a stack allocated string buffer) and hence CTD, or whether you're going to overrun your global buffer and overwrite something important (if you've got DEP turned on, you may find some more interesting behaviour), however it WILL inform you of a buffer overrun and Assert to stop execution. safe_strings will now also give you the buffer size and the text that you're trying to stuff into it.
The #1 Antipodes build contained safe_strings and was posted 24/July, so you've all had the best part of a week to figure out whether or not safe_strings will affect you (because of the number of files changed - 168, maintaining the branch in that state for longer than a week would introduce larger chances of making mistakes during the merge into trunk)

On the code side, safe_strings will do a number of things:

Please report any instance of safe_strings asserting (you will need a debug build in order to do this) - we will not be able to fix your problem if you do not forward the relevant information to us.


portej05
Title: Re: The deal with safe_strings
Post by: Echelon9 on July 30, 2009, 04:26:56 am
I want to stress how beneficial a change safe_strings is.

We've been working behind the scenes for a number of weeks now to ensure it is a stable land onto the trunk branch, and the Debug fs2_open.log reporting is sufficient to work out what went wrong in the code base to cause the overrun.

portej05 deserves a big thanks for helping make FSO much more stable and secure.