0

I am writing an application which has to find the sub string from a file and write this sub string into some different file. For writing into a file , I am using fputs, but someone told me to check the safer version for writing into the file.

while (fgets(line, MAX_LINE_LEN, fp1) != NULL) {

        if (pname_count < 1) {
            if (strstr(line, p_name)) {
                pname_count++;
                fputs(strstr(line, p_name), fp2);// danger.
                continue;
            }
        }
       //Remaining code

    }

Followed two below links, but did not get my answer exactly.

gets() and fputs() are dangerous functions?

fputs dangerous in C

Can someone explain what is the vulnerability with "fputs" in terms of safety.?

Since fwrite takes the number of characters to write into the file, does this make fwrite more safer than fputs?

ppandey
  • 311
  • 2
  • 3
  • 9
  • @JensGustedt That's false. All stdio output functions (including `fputs` and `fwrite`) write characters consistently, as if by calling `putc`. The decision to convert `'\n'` is based on whether the file was opened with the `b` modifier or not. – Steve Summit Mar 17 '18 at 21:32

2 Answers2

6

I don't believe that fputs is dangerous in any inherent way. I believe that other question was mistaken for suggesting that it was.

You asked if fwrite was safer than fputs because of the explicit count. I don't think we can say so; I believe this cuts both ways:

  • fputs deals in null-terminated strings, so if you accidentally pass a string that's not properly null-terminated, fputs will sail off the end, and weird things may happen. And programmers certainly do make this mistake.

  • But it's just about as easy to accidentally pass the wrong count to fwrite. In particular, if you're writing (what you think is) a null-terminated string, you're probably going to call fwrite(str, 1, strlen(str), fp), which is obviously going to have exactly the same problem.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
2

No risk.

As long as your string is properly terminated, nothing bad can happen.

however here:

fputs(strstr(line, p_name), fp2);

the result of strstr can theorically be NULL, so you could crash your program trying to write NULL.

No risk of code injection here, though.

Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219
  • In theory, the risk here is the unchecked (highly risky) use of the result of `strstr()`, not `fputs()` itself. However, the code is repetitious; it invokes `strstr()` first and checks that the result is non-null before calling `fputs()` — and calling `strstr()` again. So, unless there are cosmic rays or other gremlins at work on the machine, or some other thread is modifying `line` (or `p_name`) at the same time, `fputs()` won't actually get a null pointer. – Jonathan Leffler Mar 17 '18 at 09:08
  • 1
    @JonathanLeffler hence the "theorically" in my statement. One should never underestimate cosmic rays... – Jean-François Fabre Mar 17 '18 at 10:22
  • On a (really slightly) more serious side: I may add that some aeronautics hardware are hardened to be able to resist electromagnetic perturbations. – Jean-François Fabre Mar 17 '18 at 10:24