Use secure versions of sprintf, fopen, and wsprintf

[jason-c-daniels]

Use Case: Consuming applications need to be as secure as possible. They can be no more secure than their least secure component. By securing the features using these functions you improve the security of client applications.

Estimated Impact:

Cons: There will be some extra coding will need to be done around fopen_s as it returns an error code value. Pros:

1. using fopen_s this will more easily allow the code to give more meaningful interpretations of various file system errors, vs, just a simple success/failure on file access.
2. Doing the rest give peace of mind to consumers.
3. Some compiler settings will prevent compilation if using the insecure alternatives. Making these changes will allow people to retain stringent security checks in their compilers without special casing the code in aria.c.
4. I can submit these changes to you if you would like. (I'm 99% done. I've not properly used the return code from fopen_s yet)

[rxi]

Regarding sprintf -- this function is only used in 3 places:

• Converting a double to a string, which should never exceed the buffer size
• Creating a type-string, which should never exceed the buffer size
• For errors, which are do not use arbitrary data, and should never exceed the buffer size (see #1)

Aria tries to keep strictly to C89. If a specific compiler refuses to compile because sprintf is being used I would be willing to add a an ifdef-wrapped define (or something to this effect) to pacify these warnings/errors, but to keep in line with the project's goal of minimalism and C89 compatibility I wouldn't be willing to replace these functions with the C99/11 alternatives.

[jason-c-daniels]

I'll work up an #ifdef macro to do this and submit a pull request, since VS2015 with security checking is what's barking about this. I pulled aria into it for memory profiling for potential leak detection. (I found none)