Great question! Let's start by walking through your examples to understand the problem clearly, then talk about why C allows this seemingly risky behavior.

Example 1: Macro shadowing without calling the library function #

#include <stdio.h>
#define scanf "%s Hello World"
int main (void) {
    printf(scanf, scanf);
    getchar();
    return 0;
}

Before the compiler even sees this code, the preprocessor does its job: every instance of scanf gets replaced with the string literal "Hello World %s". So the line printf(scanf, scanf) expands to printf("%s Hello World", "%s Hello World"), which outputs:

%s Hello World Hello World

Since we never try to call the actual scanf function here, everything works fine.

Example 2: Conflict when trying to use the real library function #

#include <stdio.h>
#define scanf "%s Hello World"
int main(void) {
    int x;
    printf(scanf, scanf);
    scanf("%d",&x);
    getchar();
    return 0;
}

This time, we hit a compile error. When the preprocessor expands scanf("%d",&x), it turns into "Hello World %s"("%d",&x)—which makes no sense to the compiler, hence the error:

main.c: In function ‘main’:
main.c:2:17: error: called object is not a function or function pointer
 # define scanf "%s Hello World"
                 ^
main.c:7:4: note: in expansion of macro ‘scanf’
    scanf("%d",&x);
    ^~~~~

So why does C allow this? #

C was built with a core philosophy: trust the programmer, and give them maximum flexibility. Here's why this behavior fits into that mindset:

• Historical roots: C was created for systems programming, where developers needed fine-grained control over their code. The preprocessor was a critical tool for code reuse, conditional compilation, and optimizing performance (think macro-based inline functions before inline was standardized). Restricting macro names would have limited this flexibility.

• Legitimate use cases: Sometimes, you want to replace a standard function with a macro. For example, you might wrap malloc to add debug tracking, or replace printf with a custom logging macro. You can still access the original function by putting parentheses around its name (macros don't expand inside parentheses):

  #define malloc(size) debug_malloc(size, __FILE__, __LINE__)
  // Call the real malloc like this:
  void* ptr = (malloc)(100);
  

• Preprocessor independence: The preprocessor is a separate step from compilation—it just does text replacement, with no knowledge of standard library functions. Keeping it simple and fast was a priority in C's early days, and adding checks for library function names would have complicated it.

• Safety is optional, but available: C doesn't force safety on you, but it gives you tools to avoid mistakes. You can use #undef scanf to remove the macro before calling the real function, or enable compiler warnings (like GCC's -Wshadow) to catch accidental name collisions.

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