《K&R C程序设计语言》中同代码编译产生不同输出问题咨询

Hey there! Let's break down why your K&R word count program might be producing inconsistent outputs—this is a common gotcha with programs that rely on standard input, but we can fix it.

First, let's confirm your code matches the K&R example perfectly (it looks spot-on!):

#include <stdio.h>
#define IN 1
#define OUT 0
int main() {
    int c;
    long int nl, nc, nw;
    int state;
    nl = nw = nc = 0;
    state = OUT;
    while((c = getchar())!= EOF){
        ++nc;
        if (c == '\n'){
            ++nl;
        }
        if (c == ' '||c == '\n'|| c == '\t'){
            state = OUT;
        } else if (state == OUT){
            state = IN;
            ++nw;
        }
    }
    printf("\n%ld %ld %ld\n", nl, nc, nw);
}

Now, here are the most likely causes and fixes:

1. Inconsistent Input or EOF Triggering #

This is the #1 culprit for variable outputs with this program.

• Why it happens: The program counts based on exactly what you input, including accidental extra spaces, newlines, or how you signal the end of input (EOF). For example:
  • On Windows, EOF is triggered with Ctrl+Z (followed by Enter), while on Linux/macOS it's Ctrl+D. Triggering EOF mid-line vs. after a newline changes the character/line count.
  • Accidentally adding an extra space or newline at the end of input will skew the numbers.
• Fix: Use a fixed input file for testing instead of typing manually. Create a file like test_input.txt with exactly the content you want to test, then run the program with input redirection:

  ./wordcount < test_input.txt
  

  This ensures every run uses identical input, eliminating human error.

2. Cross-Platform Line Ending Differences #

Line endings vary between operating systems, which affects the character count (nc):

• Why it happens: Windows uses \r\n (two characters) for newlines, while Unix-like systems (Linux/macOS) use \n (one character). Your program counts \r as a regular character, so a Windows-formatted input file will have a higher nc than the same content in Unix format.
• Fix: Convert your input file to match your system's line ending format. Use tools like dos2unix (Windows to Unix) or unix2dos (Unix to Windows) to standardize line endings before testing.

3. Compiler/Compile Option Inconsistencies #

While your code is standard C, different compilers or flags can cause subtle differences (though rare here):

• Why it happens: For example, compiling with optimization flags like -O3 sometimes and without other times, or switching between GCC, Clang, or MSVC, could lead to edge-case behavior changes.
• Fix: Stick to a consistent compile command every time, e.g.:

  gcc wordcount.c -o wordcount
  

  Avoid adding random flags unless you know exactly what they do.

Test Case to Verify #

Let's use a concrete example to confirm your program works. Create test_input.txt with:

Hello world
This is a test

When you run ./wordcount < test_input.txt, the expected output is:

2 23 6

(2 newlines, 23 total characters including spaces/newlines, 6 words). If you get this every time, your program is working correctly—any variance is due to input/environment issues above.

内容的提问来源于stack exchange，提问作者user279540