From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 4E1F03858D1E for ; Tue, 24 Jan 2023 17:58:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E1F03858D1E Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=golang.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-ej1-x629.google.com with SMTP id mg12so41195524ejc.5 for ; Tue, 24 Jan 2023 09:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golang-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ViSByJQf8DdV7r2VjCckH0WQU8GK3FEdYWW4x+thgjI=; b=LKFviWBCIGg1T7uwBPktVCtmxlj/juNo3b618xJG4gfxBiWONVEtkf80cw5IupQSc0 LmBZUliaBVXX3xzg1+bsQJCCb3F/6Hu8+V+a0jkcz82gqXvK1+7cgi0OcTp7+VyDEvEz zm9oqiK+jjoLfGOl9mRr8p3e6tKtq4mVRcgQMbhBMeng0oIYO94umjg8jH3eCixYgNzy q1H1pohTqfMfRS03tCdFXPIPmX+EPGTdcZpUbn8GcW8KOSCkGqBegG33fcxxsswn3+FV pRtwmo4593s1uBs6c9MlLOkmR8CpRc1x+cpvY28z/89x/FGKfZhWu7SUbSwUnu2RzCKW 43tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ViSByJQf8DdV7r2VjCckH0WQU8GK3FEdYWW4x+thgjI=; b=G022SvAud2MRO2zXbmPNWNsg9WsjbhU/k6sBqZw4rUoLlmd4WSw8E7JqTGXBk3hUDQ 8CVLZnd5qdSM7XxNcPFz+Q3OhszTomU16h2xTlHVMO7QpZ+GHFfi1HYSqEZ2WNoxCrWi eo9bGMFmD8BrIVLcZpEyR/Of5Nrse0fEhBwV78OXwKNpDn/wxkkDXYag87EAcu5dVUzg sL5EOYTE7/xyHCvxhDcV4joYNudMw8BmbYD6x/ou80njj5gpHX/4hY9oApsUh55yHwyq kYXq/toenJJa1qZVxWU4IHxu5H2LFL08yEutHw1qQgyv2PhatwwWFrB/rNegEmu30Vnr K+bQ== X-Gm-Message-State: AFqh2kpfS2Eg+6vfwJNefp/ahi/E61mhjyGByhCritRtU2c8JvwNSW+R LcuT3Xmgt8peWg/WszTRTY3uTp89Qf9e9px8UvzO/A== X-Google-Smtp-Source: AMrXdXurKwkeW9Cd30cmPxkZRpH5igZAUcDat4n/CoJHrKIgAt1sKUP4akwH5QqruVuS9Zhqv4yBibbl2USYu2GByb0= X-Received: by 2002:a17:906:b81a:b0:86a:2c18:e41c with SMTP id dv26-20020a170906b81a00b0086a2c18e41cmr2393163ejb.237.1674583101643; Tue, 24 Jan 2023 09:58:21 -0800 (PST) MIME-Version: 1.0 References: <20230120105409.54949-1-gcc@hazardy.de> <20230120105409.54949-2-gcc@hazardy.de> <83tu0ggjro.fsf@gnu.org> <83o7qnho2o.fsf@gnu.org> In-Reply-To: <83o7qnho2o.fsf@gnu.org> From: Ian Lance Taylor Date: Tue, 24 Jan 2023 09:58:10 -0800 Message-ID: Subject: Re: [PATCH 2/4] libbacktrace: detect executable path on windows To: Eli Zaretskii Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jan 24, 2023 at 8:53 AM Eli Zaretskii via Gcc-patches wrote: > > > 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. OK, thanks. I'd rather that the patch look like the appended. Can someone with a Windows system test to see what that builds and passes the tests? Thanks. Ian