The code is working nice for me.
But feel free to give me advice.
Code:#include <stdio.h> #include <stdlib.h> #define SIZE 100 int main(int argc, char** argv) { FILE *pFile; char string[SIZE]; if ((pFile = fopen("code.txt", "rt")) == NULL) { printf("error"); return -1; } while (fgets(string, sizeof (string), pFile) != NULL) { if (printf("%s", string) < 0) { puts("Error printf"); fclose(pFile); return -1; } } fclose(pFile); return (EXIT_SUCCESS); }
Last edited by thinkabout; 07-10-2017 at 06:44 AM.
Perhaps specify the file to show via command line arguments (argv).
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Originally Posted by Salem
Code:if ((pFile = fopen(argv[1], "rt")) == NULL) { printf("%d %s\n", errno, strerror(errno)); return -1; }
The character 't' in the "mode" argument to the fopen() call is non-standard and has undefined behavior. If you want to open the file in "text" mode, just leave out the 't'.
It is not undefined behaviour. System-dependent extra characters are allowed after the standard sequences and are meant to be ignored if not understood. I recall something about being able to set Windows so that the default opening mode was binary, so the text mode flag could be necessary.
fopen, _wfopen
You can't even be sure of a standard non-standard behaviour with M$.If t or b is not given in mode, the default translation mode is defined by the global variable _fmode. If t or b is prefixed to the argument, the function fails and returns NULL.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Ah, you're right. The C11 (draft) standard says:
but that has a footnote:The argument mode points to a string. If the string is one of the following, the file is open in the indicated mode. Otherwise, the behavior is undefined.
r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
rb open binary file for reading
wb truncate to zero length or create binary file for writing
ab append; open or create binary file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create text file for update
a+ append; open or create text file for update, writing at end-of-file
r+b or rb+ open binary file for update (reading and writing)
w+b or wb+ truncate to zero length or create binary file for update
a+b or ab+ append; open or create binary file for update, writing at end-of-file
so it's undefined behavior, unless the implementation either supports the trailing characters or chooses to ignore them.If the string begins with one of the above sequences, the implementation might choose to ignore the remaining characters, or it might use them to select different kinds of a file
In any case, unless you need a special mode, and you know your application is going to run on a specific implementation that supports it, then I recommend sticking to one of the standard modes.
