From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=4YeA=5S=gnu.org=gcc-refused-email@sourceware.org>
Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e])
	by sourceware.org (Postfix) with ESMTPS id 399FB3858D20;
	Sat, 21 Jan 2023 09:25:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 399FB3858D20
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=MIME-version:References:Subject:In-Reply-To:To:From:
	Date; bh=DYhDG/ZU5wO3OWOoeYGYZWZ4hHfJo7PPePrxG1MmUfI=; b=hOT1WHZvbVV2cJGsI4gc
	rHJAomRsqxoWdYOBhzvDqxidZhixR/9VIUP9HEQaednjD0I8j/jBBp2ejn7X3gtC3ktwftr1OwD3U
	XIJtESp6KIWz/juw2y5w0fK2Ye65noSffMJWbbCguyxnpriKySTQ5UuuuWKH3WrCBpZJDug2R1vFl
	0X36josvA54qg5INPZbxvwlr1uNdiOZFpFjLSH5mtu+6u3W3FiRTXch54LtUzLvhkUvAv7xjIV/Pc
	mQmZJiJrgUmg1lFmSkWuBpHBGn7bqBGt5hXuF5+NL1hK9llxpQHpRtZ/fhM0sLAC20+sSjNQFPbME
	apmxpzB/2ARD0g==;
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 <eliz@gnu.org>)
	id 1pJA7V-0003FX-DC; Sat, 21 Jan 2023 04:25:05 -0500
Date: Sat, 21 Jan 2023 11:25:06 +0200
Message-Id: <83wn5gkznx.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: LIU Hao <lh_mouse@126.com>
Cc: gabravier@gmail.com, gcc@hazardy.de, gcc-patches@gcc.gnu.org,
	gcc@gcc.gnu.org
In-Reply-To: <39182605-c77f-ccaf-f9dc-bd879a52831f@126.com> (message from LIU
	Hao on Sat, 21 Jan 2023 17:18:14 +0800)
Subject: Re: [PATCH 3/4] libbacktrace: work with aslr on windows
References: <20230120105409.54949-1-gcc@hazardy.de>
 <20230120105409.54949-3-gcc@hazardy.de> <83zgadmik1.fsf@gnu.org>
 <e1e2342c-27f1-7cec-787e-23b4c6dfee6b@gmail.com> <83k01hm2sm.fsf@gnu.org>
 <64148e01-15a1-0331-ad52-bf131403ed76@gmail.com> <83h6wkmt0t.fsf@gnu.org> <39182605-c77f-ccaf-f9dc-bd879a52831f@126.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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 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: <gcc.gcc.gnu.org>

> Date: Sat, 21 Jan 2023 17:18:14 +0800
> Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
> From: LIU Hao <lh_mouse@126.com>
> 
> 在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道:
> > I'm not sure I follow the logic.  A program that calls
> > GetModuleHandleW will refuse to start on Windows that doesn't have
> > that API.  So any version before XP is automatically excluded the
> > moment you use code which calls that API directly (i.e. not through a
> > function pointer or somesuch).
> 
> Are _you_ still willing to maintain backward compatibility with Windows 9x? Even mingw-w64 has been 
> defaulting to Windows Server 2003 since 2007. Why would anyone build a modern compiler for such old 
> operating systems?

I'm only saying that we should not deliberately break those old
platforms unless we have a good reason.  And I see no such good reason
in this case: GetModuleHandleA will do the job exactly like
GetModuleHandleW will.

> With any Windows that is modern enough, wide APIs should always be preferred to ANSI ones, 
> especially when the argument is constant. Almost all ANSI APIs (the only exception I know of is 
> `OutputDebugStringA` which does the inverse) translate their ANSI string arguments to wide strings 
> and delegate to wide ones, so by calling wide APIs explicitly, such overhead can be avoided.

The overhead is only relevant in code that is run in performance
critical places.  I don't think this is such a place.