Fix Backwards fopen_s Check

[Calandracas606]

fopen_s, (and the defined macro), return 0 on success, but the if statement is expecting a non-zero value on success.

This causes cl_util_write_binaries to fail, even though it is successfully opening a file.

Can be tested very easily by building and running the "binaries" sample program.

[Calandracas606]

Would it be reasonable to simply replace the fopen_s() calls with equivilant fopen()?

fopen_s is not widely supported, and can cause confusion, especially when it is redefined as a macro

[bashbaug]

Thank you for the fix!

Longer term I think it would be better (less cognitive burden) to change this to use the IF_ERR macro similar to the other calls to fopen_s, which would keep the error condition consistent. This can happen in a subsequent PR, though.

[bashbaug]

Would it be reasonable to simply replace the fopen_s() calls with equivilant fopen()?

We discussed this in our weekly teleconference and I don't think there's a right answer here: I agree that the "secure" fopen_s widely supported right now, but we also want the SDK to build warning-free on all of our configurations without needing things like _CRT_SECURE_NO_WARNINGS, so we're going to stick with fopen_s for now. We will re-evaluate if we keep running into issues like these in the future - thanks!

[MathiasMagnus]

Ship it.