Do you just meant an attempt to include a file path that couldn't be found? That's not a correct usage of the term "program" – that refers to the binary output of the compilation process, whereas you're taking about the source files that are the input to the compilation. That sounds a bit pedantic but I really didn't understand what you meant.

I just checked, and if you attempt to include a file that cannot be found (in the include path, though it doesn't use that exact term) then that's a constraint violation and the compiler is required to stop compilation and issue a diagnostic. Not undefined behaviour.

▲

kazinator 4 days ago | parent [-]

Yes; we are more interested in the other case: it happens to be found.

What are the requirements then?

▲

quietbritishjim 4 days ago | parent [-]

I don't get your point then. If the file is found then there is no undefined behaviour in the process of the file being included. There might be undefined behaviour in the overall translation unit after the text has been substituted in, but that's nothing to do with the preprocessor.

	▲	kazinator 4 days ago \| parent [-]
		> If the file is found then there is no undefined behaviour in the process of the file being included. Correct; but processing doesn't stop there. > There might be undefined behaviour in the overall translation unit But what does that mean; how do you infer that there might be undefined behavior? Does ISO C define the behavior, or does it not? ISO C has nothing to say about what is in #include <winkle.h> if such a header is found and didn't come from the program. Without having anything to say about what is in it, if it is found at all, ISO C cannot be giving a definition of behavior of the tokens that are substituted for that #include.