Evil elements in header search path cause havoc

Clang Frontend
1

Hi clang-devs,

[ esp @thakis @rnk for touching this last ]

We have a surprised user basically doing this:

$ mkdir NOX
$ chmod a-x NOX
$ touch ISFILE
$ mkdir GOOD
$ touch GOOD/header.h
$ echo '#include <header.h>' | clang -INOX -IISFILE -INO -IGOOD -x c++ -fsyntax-only -

<stdin>:1:10: fatal error: cannot open file 'NOX/header.h': Permission denied
#include <header.h>
         ^
1 error generated.

HeaderSearch::getFileAndSuggestModule() allows the -IISFILE and -INO (i.e. directory doesn’t exist) cases but errors out on the -INOX case.

To me, the approach seems inconsistent. As a user I might not care about some -Ifoo causing trouble as long as there’s another -Ibar pointing to the header just fine. I could imagine that if the header cannot be found at all, then issuing the diagnostics encountered during the search could be helpful. I.e. this:

$ echo '#include <header.h>' | clang -INOX -IISFILE -INO -IGOOD -x c++ -fsyntax-only - # finds GOOD/header.h
$ echo '#include <nope.h>' | clang -INOX -IISFILE -INO -IGOOD -x c++ -fsyntax-only -
<stdin>:1:10: fatal error: 'nope.h' file not found
#include <nope.h>
         ^~~~~~~~
<stdin>:1:10: info: -INOX: permission denied
<stdin>:1:10: info: -IISFILE: not a directory
<stdin>:1:10: info: -INO: not found

Would that be an improvement that I should propose for review, or are there good reasons to keep the current behavior?

Cheers, Axel

2

I don’t think that would be an improvement since it would mean that different users running the same command could silently get different results based solely on permissions (the example removes execute permissions on the directory for all users, but in general, permissions could differ; and I don’t recall how chmod interacts with access control lists).

3

Thanks Tom. I believe the inconsistent scenario you describe is already the case for chmod go-r, and the only option to make it consistent for all users is to require a+rx which doesn’t sound plausible.

I.e. I don’t find this argument convincing / relevant yet. On the contrary I perceive the inconsistency where some error modes are acceptable (file instead of dir, dir not readable or not existing) and others are not as far more significant.

4

I was surprised to hear that inaccessible header files would be silently ignored, so I checked and found that both gcc and clang (on Linux) report an error if an attempt to check for the existence of a header in a search path fails due to permission errors or if a found header file is not readable. If you have an example where an inconsistent result is produced, I would like to hear about it.