> > Background: I'm trying to debug some test failures in Clang, due to a
> > warning that's supposed to be issued when you #include "foo.h" but the
> > file on disk that it opened is "Foo.h".
sounds like Clang is misbehaved. If it opened the file regardless of case it
should just continue. Is it doing a gratuitous stat() call or something else to
compare actual vs requested? Why? That's just unnecessary meddling and
introducing breakage for no good reason. actually stat() is "broken" as it just
blindly returns the command-line argument rather than the accurate
representation of what is ON the disk.
My spidey sense says we had a whole conversation about this and Cygwin lying to
the user some years back.
System.IO.FileInfo() lies. The only "easy" solution I have is run powershell>
(get-Item $pwd).GetFiles('foo.h').Name
which will give you the correct answer.
Similarly PS> (get-item("foo.h*")).Name
emits the correct case. Please note the wildcard is MANDATORY for it to work.
Basically the .Net API properly handles case. The windows systemcall APIs do
not.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple