Re: [PATCH v2] Windows: Normalize backward slashes to forward slashes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 1 Jul 2026 20:28:32 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> >> +* GDB now normalizes backslashes to forward slashes on Windows.
> >> +
> >> +  E.g., depending on compiler and build system used by your project,
> >> +  previously GDB could show a mix of slash styles, like for example:
> >> +
> >> +     C:/proj/src\main.c
> >> +
> >> +  GDB will now consistently show forward slashes:
> >> +
> >> +     C:/proj/src/main.c
> >> +
> >> +  This affects everywhere GDB shows a filename/dirname: source
> >> +  filenames, executable filename, shared libraries, the cd/pwd
> >> +  commands, etc.
> > 
> > Should this mention GDB/MI output?  Someone might not guess that it's
> > covered by "etc.", given that the other examples are from quite
> > different use cases.
> 
> How about this?
> 
>   This impacts all interpreters, including the CLI, the TUI, the
>   GDB/MI interface, and the Debug Adapter Protocol, and affects
>   everywhere GDB shows a filename/dirname: source filenames,
>   executable filename, shared libraries, the cd/pwd commands, etc.

Much better, thanks.

> >> +char *
> >> +normalize_slashes (char *path)
> >> +{
> >> +  for (char *p = path; *p != '\0'; ++p)
> >> +    if (*p == '\\')
> >> +      *p = '/';
> >> +  return path;
> >> +}
> > 
> > Ehm... GNU Coding Standards frown on using "path" for anything but
> > PATH-style directory lists.  So maybe we should use "filename" or
> > somesuch, here and elsewhere.
> 
> Yeah, I had made an effort to avoid it in the NEWS entry for that reason.
> 
> For the code itself, I think that's a losing battle, the file itself
> is called pathstuff.c, described at the top as:
> 
>   /* Path manipulation routines for GDB and gdbserver.
> 
> It's full of functions using "path" as I was using, and then used throughout GDB,
> like:
> 
>  $ grep path ../gdbsupport/pathstuff.h  | grep extern
>  extern char *normalize_slashes (char *path);
>  extern gdb::unique_xmalloc_ptr<char> gdb_realpath (const char *filename);
>  extern std::string gdb_realpath_keepfile (const char *filename);
>  extern std::string gdb_abspath (const char *path,
>  extern const char *child_path (const char *parent, const char *child);
>  extern std::string path_join (gdb::array_view<const char *> paths);
>  extern bool contains_dir_separator (const char *path);
> 
> Then you have standard functions/symbols like realpath, GetFullPathName, PATH_MAX, etc
> (used by that file).
> 
> So "path" is pretty well established, including in POSIX and Windows APIs, and I don't
> think GDB developers end up confused.

I know, but I thought that maybe the new function you are adding could
use filename?

> Honestly, I think using the GNU terminology confuses more people than helps.  
> Recently in the DWARF committee I pointed out the GNU terminology to people, and
> everyone seemed surprised and confused, and I think thought I was being weird.  :-P
> 
> If I were to have say in this aspect of the GNU coding standards, I would rather come
> up with a more precise name for the PATH-style directory lists case than fight about what
> does "path" mean.

I understand.