From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id A41C83858C30; Tue, 24 Jan 2023 16:52:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A41C83858C30 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org 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=MkJJjfc9BtQDpfmKr0uuy7kt1URj1Vl6Hu9v9RwM6UI=; b=N5AINNzL3bW4 /O/odMeYZ1UQHOmHhpMvTecE1VMrhDCj7Qi9p+1Dxh2D07QimoAVPzgSXJ5UDvJj4A8cK1jewRx7+ nswCI3P4gm2Rno0JuqIHbwjS5gtByKRuXKFUzsOFul91XcxyoWskDHhJMcvW0OBDaQFvM5MuCZMQu oWvMc0/nxmluWHTqyjmC90SsT0v3wtQcLZS9+y6Lr1BkvHlnsF3mXz3B8w1PsVwRYgn2xkF9+wov+ cKgCjv1fyf0Qg8wqrwvfJvSxFif+4EhPaNk6LlXPjwIIQjW9foq7UPdrOHBAIfogcRCwQycExa7wJ rrUlrfyiDJj195WicP+F5A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKMXE-0002vH-LA; Tue, 24 Jan 2023 11:52:37 -0500 Date: Tue, 24 Jan 2023 18:52:47 +0200 Message-Id: <83o7qnho2o.fsf@gnu.org> From: Eli Zaretskii To: Ian Lance Taylor Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: (message from Ian Lance Taylor on Tue, 24 Jan 2023 06:35:21 -0800) Subject: Re: [PATCH 2/4] libbacktrace: detect executable path on windows References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-2-gcc@hazardy.de> <83tu0ggjro.fsf@gnu.org> X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Ian Lance Taylor > Date: Tue, 24 Jan 2023 06:35:21 -0800 > Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org > > > > On Windows it seems that MAX_PATH is not > > > a true limit, as an extended length path may be up to 32767 bytes. > > > > The limit of 32767 characters (not bytes, AFAIK) is only applicable > > when using the Unicode (a.k.a. "wide") versions of the Windows Win32 > > APIs, see > > > > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation > > > > Since the above code uses GetModuleFileNameA, which is an "ANSI" > > single-byte API, it is still subject to the MAX_PATH limitation, and > > MAX_PATH is defined as 260 on Windows headers. > > Thanks. Should this code be using GetModuleFileNameW? Or would that > mean that the later call to open will fail? We'd need to use _wopen or somesuch, and the file name will have to be a wchar_t array, not a char array, yes. So this is not very practical when file names need to be passed between functions, unless they are converted to UTF-8 (and back again before using them in Windows APIs). And note that even then, the 260-byte limit could be lifted only if the user has a new enough Windows version _and_ has opted in to the long-name feature by turning it on in the Registry. Otherwise, file names used in "wide" APIs can only break the 260-byte limit if they use the special format "\\?\D:\foo\bar", which means file names specified by user outside of the program or file names that come from other programs will need to be reformatted to this special format. > 260 bytes does not seem like very much for a path name these days. That's true. But complications with using longer file names are still a PITA on Windows, even though they are a step closer to practically possible.