1

I have a super simple program

#include <stdio.h>

int main(){

    FILE *fp;
    fp = fopen("test.txt", "w");

}

It shows a Microsoft Debug Assertion Failure. Then in the Error list it shows error C4996. This states that

'fopen': This function or variable may be unsafe. Consider using fopen_s instead.

BUT even when using this, it still shows the warning. Can someone tell me why this block of code won't create a file for me.

Adding a close statement will not fix it.

Could it be a software problem (Using VS).

Test Email
  • 11
  • 4
  • 1
    Does `"test.txt"` already exist?, ( `fclose()` should also be called btw) – ryyker May 01 '20 at 20:23
  • 1
    The message should also say that adding `#define _CRT_SECURE_NO_WARNINGS` at the top of your code will suppress the warning. The full warning is: `warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.` – Retired Ninja May 01 '20 at 20:24
  • I can't yet see how this program would cause an assertion failure. It is as if code is missing that runs after the (possibly failed) `fopen` call. – E. van Putten May 01 '20 at 20:26
  • @ryyker. No the file does not exist – Test Email May 01 '20 at 20:35
  • @E.vanPutten I have no clue why this isn't working – Test Email May 01 '20 at 20:36
  • @RetiredNinja No, it doesn't. I still am not able to create the file and the same error occurs. – Test Email May 01 '20 at 20:37
  • 1
    I think the important thing to do is not confuse the warning that you can easily suppress with any error you might have. They are not related in any way. I had no trouble running your code both when the file could be created and also when it could not due to permissions. Is your example the exact code you are running or is this just a smaller example of the real code? When you get the debug assertion the debugger will break in a particular place. Which file/line is that and what is the exact assertion message? – Retired Ninja May 01 '20 at 20:42
  • @RetiredNinja Tried some other things that happened to get rid of the assertion error. Now the thing is that it won't create a new file, but will open previous ones. – Test Email May 01 '20 at 20:47
  • 1
    Well, without knowing what "some other things" are I have no advice for you. Looking at the runtime library source code there are a few reasons `fopen` would assert. I'd guess the filename or mode are either null or empty, but having the full assert message would narrow that down to a specific problem. – Retired Ninja May 01 '20 at 20:52
  • @RetiredNinja The exact problem is that although there are absolutely no warnings...the code still won't create a file. No matter how I format, it still won't create. NO warnings at all. – Test Email May 01 '20 at 20:55
  • As long as you don't fix the error you are still running an older version of your program that doesn't match the code you are showing us. – E. van Putten May 01 '20 at 20:58
  • 1
    If `fopen` returns NULL you can examine `errno` for the error value or use `perror("Error");` to print a readable form of it. – Retired Ninja May 01 '20 at 20:59
  • Errors are gone! Cannot create files with this code. – Test Email May 01 '20 at 20:59
  • Does this answer your question? [fopen deprecated warning](https://stackoverflow.com/questions/14386/fopen-deprecated-warning) – Hitokiri May 01 '20 at 21:12
  • Yes...That took care of the first problem. – Test Email May 01 '20 at 21:17
  • Can you post the full assertion failed message? – E. van Putten May 01 '20 at 21:25
  • 1
    Microsoft probably wants you to use `fopen_s()` instead of `fopen()`. There isn't a huge benefit to doing so — unless you want the benefits of the extra `'u'` and `'x'` flags. – Jonathan Leffler May 01 '20 at 21:25
  • 1
    I'll take one more stab at this. If your program is not creating the file then `fopen` is failing. The way you check for that is by checking if the returned pointer is NULL. If it is you can find out why it failed by using the recommendation in my previous comment. You've said "Errors are gone!" but not creating the file is a runtime error and one you should check for and have a plan to recover from. If `fopen` is returning a valid pointer then the file was created but perhaps somewhere you didn't expect because the working directory in the debugger is something you didn't expect. – Retired Ninja May 01 '20 at 21:55
  • 1
    OP's turn now to listen to the wise Ninja and check for the error number after fopen fails (when it returns null pointer) and/or mention the assertion failure message details here. – E. van Putten May 02 '20 at 07:11

0 Answers0