From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id D4B3EDT3RWqeCyIAWB0awg (envelope-from ) for ; Thu, 02 Jul 2026 01:29:24 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mL+/5iJU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 289AC1E070; Thu, 02 Jul 2026 01:29:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5FF1A1E070 for ; Thu, 02 Jul 2026 01:29:22 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B7FDA4BA23CB for ; Thu, 2 Jul 2026 05:29:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B7FDA4BA23CB Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mL+/5iJU Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id DB01D4BA2E0A for ; Thu, 2 Jul 2026 05:28:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB01D4BA2E0A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB01D4BA2E0A Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782970137; cv=none; b=OGtTOaTqgF3TTpgdgr6sHt/n2gRfEz39R93elX66k1UV4Hffp+fpsCe7cGFKeAnKrNMf9dftQayje+nJ1SqxhgsCAH9nR65KZZjdYkon1GRZnIcVY+CvA1rt3gJj1MZeKO2XXz2GH2vV6DgXVe6ywauWf0+PaN7KBX4XE0fDgOw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782970137; c=relaxed/simple; bh=rMU8GrpifOlmzC/gA5WvrYfkO5QlimQMUAbvYG9n/D8=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=UO4EddOWFOh+LKC2BKuKM1dCD/UKwHOiD8OxJa2U+/C9Mo/AH9Jj34bg2jCk+s0kr+Tq6aEN3d9Cx/Wa2dvdzmYnNGqtTXvsM5cbZjR7lmrsrQ0/inQ+EvtoUAUXCWvdb9qqF9YrqI5mSryrOEYaH58XPZFT3TR0DD2eaIVpRIE= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=mL+/5iJU DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB01D4BA2E0A Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wf9yo-0007GE-Iz; Thu, 02 Jul 2026 01:28:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rdtvGo7vKdeMDQkUff4G1ClEmrxXw/F26BAghVmOsfo=; b=mL+/5iJU4vJX MnJTHOGJS02voUjDp1aIkjOthjFVPsmnzEhapkho0Dmq5A/ccGk8PoUhYpSHa84+ni+CrOHHvYt61 c3x1sxtf9pv0Xc+zuPuSwFxTLL1OUm+leKq/nOgGfgGATcS01LeYHva70MY+Sg69i+adANz4KehWr wzLZlO9vv4DikErNimp74fDGmZ4RV6U20WeWXfuIwWoNT1of5NGg+E/D9wbQSLwB8V3SFM2gSZg5+ DtJ3Jud1W9DRZCZiJRcg00ie3U8PWROdN3ZNFCKuRx/hrmSvpfz/pqDluILsngO/ERuotVPxfbE72 mLM5yIhmPIyN4oXlY5aPdA==; Date: Thu, 02 Jul 2026 08:28:50 +0300 Message-Id: <86y0fuarjh.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Wed, 1 Jul 2026 20:28:32 +0100) Subject: Re: [PATCH v2] Windows: Normalize backward slashes to forward slashes References: <20260629212430.340516-1-pedro@palves.net> <867bnge0bc.fsf@gnu.org> <86qzlocbb4.fsf@gnu.org> <86fr22diax.fsf@gnu.org> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > Date: Wed, 1 Jul 2026 20:28:32 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > >> +* 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 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 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.