Interview question?

[Keith Thompson]

With #include "stdio.h", if ./stdio.h cannot be found, it is treated as if
it were #include <stdio.h>, therefore including /usr/include/stdio.h (or
wherever the standard header is, and regardless of whether it's actually a
file).

Not quite. The standard says nothing about "./" or "/usr/include"
(you acknowledged the latter, but not the former). It's not even
clear that "./stdio.h" refers to "stdio.h" in the current directory;
there might not be such a thing as a "current directory", and if there
is, it might not be called ".", and "/" might not be a valid directory
delimiter.

``#include "stdio.h"'' causes the file identified by ``stdio.h''
(which may or may not be a file *named* "stdio.h") in a sequence of
implementation-defined places. If that search fails, the directive is
then reprocessed as if it said ``#include <stdio.h>''.

So ``#include "stdio.h"'' is very likely to work, but it can fail if
there happens to be a file named stdio.h, or rather identified by the
character sequence ``stdio.h'', in the implementation-defined search
path.

 

[Army1987]

``#include "stdio.h"'' causes the file identified by ``stdio.h''
(which may or may not be a file *named* "stdio.h") in a sequence of
implementation-defined places. If that search fails, the directive is
then reprocessed as if it said ``#include <stdio.h>''.

So ``#include "stdio.h"'' is very likely to work, but it can fail if
there happens to be a file named stdio.h, or rather identified by the
character sequence ``stdio.h'', in the implementation-defined search
path.

If we want to be *really* pedantic, 7.1.2 says "If a file with the same name as one of the above < and > delimited sequences, not
provided as part of the implementation, is placed in any of the standard places that are
searched for included source files, the behavior is undefined.", so
having a "file" with that "name" in that "place" is Bad even if
`#include <stdio.h>` is used.