bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [v2 PATCH] canonicalize-lgpl: Return file name using '/' consistentl


From: Bruno Haible
Subject: Re: [v2 PATCH] canonicalize-lgpl: Return file name using '/' consistently on MinGW.
Date: Sun, 12 Dec 2021 19:34:51 +0100

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]