From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0HO/Ed7cQ2oThB8AWB0awg (envelope-from ) for ; Tue, 30 Jun 2026 11:12:30 -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=VtVkXm7b; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 38A801E024; Tue, 30 Jun 2026 11:12:30 -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 0B8251E024 for ; Tue, 30 Jun 2026 11:12:29 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C83454BA23CA for ; Tue, 30 Jun 2026 15:12:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C83454BA23CA 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=VtVkXm7b Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4FFB14BA2E26 for ; Tue, 30 Jun 2026 15:12:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4FFB14BA2E26 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 4FFB14BA2E26 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=1782832323; cv=none; b=ZnZEoQKQoPblMNl1On3tU2nv0XW9eaOOW0dpej6DPg3slwUHmgB4A7jpa5g2HA1ouMuq6zS4pv3YvFoSfC/9ST41KBv+SK+5amoHw7gu/gMSyUBQAFvA1zhHj4N9lWsEQg3maroZbJslukyrUZ+PdXFzpRi9DlmGzr2qeHCOeSY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782832323; c=relaxed/simple; bh=x9PyhC0hr49FN1K4+s72wg4535S4m/4TxQoyHvluMgE=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=eyYgfsetXyhjup7j/9mLNXrdTbTUC0k4/iAhFqIKNG3nHSDep8oIIO/aTvraNqlFcZXemhK7I3GYOOrNcMzzXWwatBQIZ7Kqj9tppFvjc0yeM0uath1WOZZj8ep0C6mpoXd1qVNfjlyV0c5S2ajnxcRbrOz1wrBn9wSnDtRMXJc= 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=VtVkXm7b DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4FFB14BA2E26 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 1wea81-0007WJ-R0; Tue, 30 Jun 2026 11:12:02 -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=6tlZuQpvmOnQq9JcUlI+aKOaRbmCy+PsZfRGuaYcOXA=; b=VtVkXm7bIF1+ 4/VGj0LYfJeVGPYddm9ig71QQKaorkYiTkSyKpKcQHjNhR6a86hFcHkDmzVBJPv5qqkAVNi0kobXa T7m+lAJgz/8t14/I4RV7JYzqaGEiiWh4Y/1y9JRKf3/7VX9ktU/yzD4l7dpb9+iD/9jaWWv4Z6Wkt 2d5Ci7SIwiWpY40jfsW/bpMe7j5aRnxG7GvVNWNuRFnkW15bBokChKVXkPmqs5id6wfKMmfDf/fYC 0rgL+V3pWxSr5FtXz05oyIcZr0TLSsOxtNNAUfQ82FBor+w74FMjNniOM6gtiklKromb8Og0OXPL1 WyTPyT0wzk8hPhCCxXD7bw==; Date: Tue, 30 Jun 2026 18:11:59 +0300 Message-Id: <86qzlocbb4.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Tue, 30 Jun 2026 15:47:54 +0100) Subject: Re: [PATCH] Windows: Normalize backward slashes to forward slashes References: <20260629212430.340516-1-pedro@palves.net> <867bnge0bc.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: Tue, 30 Jun 2026 15:47:54 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > On 2026-06-30 12:26, Eli Zaretskii wrote: > >> From: Pedro Alves > >> Date: Mon, 29 Jun 2026 22:24:30 +0100 > >> > >> Starting program: C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.rocm/simple/simple > > > > Are forward slashes only shown to the user, or does the code pas the > > file name with forward slashes to CreateProcess? (I'm not familiar > > with thecode enough to determine which one myself, sorry.) If we pass > > forward slashes to CreateProcess, it could cause problems, IME; it is > > much safer to use backslashes there. > > We now pass forward slashes down to CreateProcess. It just works on my Windows 11 machine, though. I forgot to > mention, but I (painfully) ran the whole testsuite before and after this patch (that's how I discovered the need > to tweak the gdb.base/set-cwd.exp testcase). > > Searching online, I found this: > > https://stackoverflow.com/questions/5652834/c-createprocess-wont-work-with-app-and-args-with-forward-slash-worked > > ... where someone said: > > "CreateProcess does work with forward-slashes on Windows 7. I'm guessing this is a version-specific feature (or bug)." > > And here: > > https://www.reddit.com/r/programmingmemes/comments/1k8ctk2/comment/mp8lvsr/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button > > Someone said: > > "At least since Windows 2000, probably since always." > > I asked an LLM, and got this: > > "That normalization is original to NT -- Windows NT 3.1 (1993). The kernel's RtlDosPathNameToNtPathName has always treated / as an alternate separator. CreateProcess > itself never "added" the feature -- it just calls through to the kernel, which handles it transparently." > > So I wonder whether what you're recalling is something from the Windows 9x days, which we no longer support (we support WinXP and up). Do you happen to recall? No, I don't. But I stopped using Windows 9X a very long time ago, and my main development machine ran XP until two years ago. So if I had to guess, I'd guess it was on XP. The articles you cite are correct in that the low-level Windows APIs which accept file names treat the forward slash as a directory separator. But CreateProcess has some application-level logic of itself: it accepts a complete command line as a single string, not as argv[]-style array, and decides by itself which part of that command line is the executable and which the rest of the command line. It is this part that I'm afraid of: it could treat the two slash variants differently. That happens before the command line gets to the low-level APIs which accept file names. > If it's really a problem on supported Windows versions, it should be a matter of converting back to forward slashes before we > call CreateProcess. We already do that in gdb/windows-nat.c:windows_nat_target::create_inferior, for "set cwd": > > /* Mirror slashes on inferior's cwd. */ > std::replace (expanded_infcwd.begin (), expanded_infcwd.end (), > '/', '\\'); > > we'd just need to do the same for exec_file. Yes, I think it's safer to convert to all backslashes in the argument we pass to CreateProcess. And it will not show outside of that place, so the (very positive and welcome) effects of your changes will not be affected. Thanks.