[cfe-dev] case-insensitive #include warning

[Eric Niebler via cfe-dev]

On 4/11/16, 4:45 PM, "Eric Niebler" <eniebler at fb.com> wrote:

>On 4/11/16, 4:12 PM, "Jason Haslam" <jason.haslam at gmail.com> wrote:
>
>>>On Apr 5, 2016, at 4:03 PM, Eric Niebler via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>
>>>I have an initial cut at patch that issues a warning when a file is #included on a case-insensitive file system that would not be found on a case-sensitive system. Is there interest?
>>>
>>>Since this is a hard problem to solve perfectly, I have opted for a strategy that is efficient and conservative about issuing diagnostics. That is, it shouldn't give false positives, but it will fail to diagnose some non-portable paths. On *nix
>>> systems, the low-level APIs that stat and open files get an extra call to ::realpath, and the result is cached along with the rest of the file metadata. […]
>>
>>I was working on a similar patch a few years ago (http://lists.llvm.org/pipermail/cfe-dev/2012-July/023090.html is
>> the start of a very long thread). Does realpath really give the real case on unix? My understanding is that it doesn’t. [...]
>
>I haven't been able to successfully mount a case-insensitive file system on my Linux VM, so I haven't specifically tested this. On Mac, realpath gets the case right, but it's not needed since it has fcntl/F_GETPATH, which I've discovered is faster. In
> my tests, realpath does not get the right case on Cygwin.


And now that I've (finally!) been able to test this on Linux, I can confirm what Jason said: on Linux, realpath does *not* give the correct case. However, most *nixes besides MacOS have /proc, and ...


>On *nixes that have /proc, it's possible to readlink on /proc/self/fd/$FD once the file is opened, and that
>should give the properly cased filename.


^^^^ I have also confirmed this. ^^^^ :-)


>I haven't done extensive benchmarking, but that is certain to be faster than recursive directory traversal. But not all *nixes have /proc.
>
>TL;DR this is going to be an unreliable warning. Personally, I think that's fine so long as it doesn't give false positives and doesn't slow things down too badly. I'm busy reworking the patch to that end.