[Bug preprocessor/61922] Recursive #include overruns Win32 MAX_PATH due to lack of path canonization

[ilya.konstantinov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922

--- Comment #6 from Ilya Konstantinov <ilya.konstantinov at gmail dot com> ---
OK, I've done some more research:

1) It turns out Windows doesn't handle parent directories from symlinks the way
*nix does, but rather just follows them out of the symlink. Same for junctions
a.k.a mountpoints. Thus, "textual canonization" is actually possible.

2) This issue is not present on cygwin gcc. cygwin implements its own path
canonization (on each 'open'). In fact, it has to, since it uses NtCreateFile
which performs no path processing of its own. [1] As a result, gcc on cygwin
should support canonical paths up to 32K, and (pre-canonization) paths of any
size. Furthermore, cygwin preserves the POSIX semantics -- i.e. "symlink/.."
leads out of the symlink's target.

3) My gcc build (from the Android NDK) is a mingw build, so uses MSVCRT fopen,
which is a thin wrapper around CreateFile. Since we're not going to change
MSVCRT, should it be a MINGW issue?

[1] see https://cygwin.com/viewvc/src/winsup/cygwin/path.cc?view=markup