From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.hazardy.de (mail.hazardy.de [78.94.181.132]) by sourceware.org (Postfix) with ESMTPS id 533193858D1E; Tue, 24 Jan 2023 21:00:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 533193858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hazardy.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hazardy.de Received: from [10.0.1.129] (hades.hazardy.de [10.0.1.129]) by mail.hazardy.de (Postfix) with ESMTPSA id EB38170056E; Tue, 24 Jan 2023 22:00:21 +0100 (CET) Message-ID: Date: Tue, 24 Jan 2023 22:00:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH 2/4] libbacktrace: detect executable path on windows Content-Language: en-US To: Eli Zaretskii , Ian Lance Taylor Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-2-gcc@hazardy.de> <83tu0ggjro.fsf@gnu.org> <83o7qnho2o.fsf@gnu.org> From: =?UTF-8?Q?Bj=c3=b6rn_Sch=c3=a4pers?= In-Reply-To: <83o7qnho2o.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am 24.01.2023 um 17:52 schrieb Eli Zaretskii: >> 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. That was basically also my reasoning for choosing the A variant instead of W.