From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 08F3A3836673 for ; Thu, 26 May 2022 17:00:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08F3A3836673 Received: by mail-io1-xd32.google.com with SMTP id q203so2222113iod.0 for ; Thu, 26 May 2022 10:00:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=apP/AiCxF5ZME5HYpfeJr3Vf9npsIRuNnDIC2ecGTBg=; b=Gn6YooSzAe27VkV357HDL2v/5lJ4drkOLAweawswrDNdsk/8IxDeExpRu+lipyTpok zCyDIJKIx8UXAa+PrUAdXL+e44CTrEgXxSkLllOcD42WFvF825cVBpczrbuvFgciE0AR qtGWxTzfN9TsxsAngGIs8J5lS2Btg6J5zcSXtMO9GfgiKaZKZkenKdpV79vx6tj6eZZV ziXkmtdkbQ2mKQAJU91h8Wu5VsaNXcMKWIaa++EzIkTEL8hpL1UP9V7aFjY5dHESOWRT PkggZucoIOx20C7Gpgj3Kbw8M3K6uzLbJOx9SrnXZ4Jzf5qbOKcGEFTWh1ludBfQX7rU eKLw== X-Gm-Message-State: AOAM533uySYO+4tk2AloaabbAs8T5ilPm2d/74yIHWgK8Tgaw6KAbH7P dg1YaxPoYjy5/mWFa1l0dSQyoSX2eDONZA== X-Google-Smtp-Source: ABdhPJw7+hVgxyq/PP1+0FEGAdSwpf7WkO4JGN/5fjHND0J07ydJ4rgLQaNWzrLX8GHlifwgO0MbWw== X-Received: by 2002:a05:6602:2f08:b0:663:9830:7815 with SMTP id q8-20020a0566022f0800b0066398307815mr10041753iow.75.1653584446356; Thu, 26 May 2022 10:00:46 -0700 (PDT) Received: from murgatroyd (71-211-158-194.hlrn.qwest.net. [71.211.158.194]) by smtp.gmail.com with ESMTPSA id y17-20020a02c011000000b0032b3a781793sm534568jai.87.2022.05.26.10.00.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 May 2022 10:00:45 -0700 (PDT) From: Tom Tromey To: Eli Zaretskii via Gdb-patches Cc: Jon Turney , Eli Zaretskii , tromey@adacore.com Subject: Re: [PATCH 1/9] Fix possible Cygwin build problem References: <20220413191756.1146768-1-tromey@adacore.com> <20220413191756.1146768-2-tromey@adacore.com> <83sfp383t5.fsf@gnu.org> X-Attribution: Tom Date: Thu, 26 May 2022 11:00:45 -0600 In-Reply-To: <83sfp383t5.fsf@gnu.org> (Eli Zaretskii via Gdb-patches's message of "Sat, 21 May 2022 15:31:50 +0300") Message-ID: <87zgj46xfm.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2022 17:00:48 -0000 >>>>> "Eli" == Eli Zaretskii via Gdb-patches writes: Eli> __USEWIDE in native Windows programming assumes the use of wchar_t for Eli> character and character strings, something that GDB sources aren't Eli> equipped for doing, at least not easily. AFAIK, Cygwin alleviates Eli> that by using UTF-8 encoded strings, but native Windows programming Eli> cannot (yet) do that safely enough on all supported Windows versions. It looks like windows-nat.c defines __USEWIDE only for Cygwin, and then is careful to use the *W forms of various Windows APIs. So maybe it works ok in practice? Eli> As long as MinGW builds of GDB support only the so-called "ANSI" Eli> encoding (i.e. the current system codepage), there's no reason to use Eli> __USEWIDE in the MinGW build of GDB, and every reason not to use it. Yeah, I think __USEWIDE is not used for mingw. However I wonder if we could remove it for Cygwin as well... that would clean up some code. Not a huge amount, but every Cygwin divergence is a bit of a pain. Tom