Jan,
> > I claim that
> >
> > * Caring about (1), (2), (3) should be done in utility functions outside
> > of
> > realpath(), since they can be useful even on relative file names.
>
> Ah right. If the need arises, I can imagine someone working on a patch
> to factor out "slashify_file_name"
Not only "if the need arises".
What I'm trying to explain is that before adding code anywhere, you should
think about:
- What are the requirements from the point of view of a program
(*not* from the point of view of a single function)?
- Does the required functionality only exist when a given, specific
function is called, or is it independent?
- Backward compatibility considerations: What can happen in existing
programs if I change the implementation of a function that the
program already uses (for a long time)?
Your approach "let me pick the realpath() / canonicalize_file_name()
function, then propose enhancements to it" does not lead anywhere.
> > Jan Nieuwenhuizen wrote:
> >> Yes, but this example shows the mixing of three problems:
> >> (1) wrong drive letter casing,
> >> (2) difference in type of slash,
> >> (3) difference in casing of the file name.
>
> Please find attached a patch that only cares about (2), because the
> seemingly arbitrarily returning of different flavours of '/' '\\' for
> the same file name is simply a bug.
It is not a bug, because
- Windows APIs treat '/' and '\\' in file names in the same way,
- As I just explained, whether slashes are better or backslashes are
better depends on the situation.
> - when you are using canonicalize_file_name to determine
> the...canonical file name...and find that it breaks on
> windows.
More precisely, you find that you had expectations about a function,
that were not backed by the documentation.
> #if __MINGW32__
Again, please don't submit GCC/mingw specific code to us. There are
at least 3 toolchains for building native Windows programs:
- GCC with mingw,
- clang with MSVC headers,
- MSVC with MSVC headers,
and they should work all the same.
Bruno
