From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bruno Haible Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: New warnings on emacs-26 branch with gcc 8.2.0 Date: Sat, 18 Aug 2018 20:33:56 +0200 Message-ID: <2778143.f1hlgcP5Av@omega> References: <86a7q0ai2z.fsf@gmail.com> <4195986.6xTypejAr3@omega> <0771b7a4-cc93-e23e-0de5-0069ce67a270@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: blaine.gmane.org 1534617127 411 195.159.176.226 (18 Aug 2018 18:32:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Aug 2018 18:32:07 +0000 (UTC) User-Agent: KMail/5.1.3 (Linux/4.4.0-130-generic; KDE/5.18.0; x86_64; ; ) Cc: Andy Moreton , bug-gnulib@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Sat Aug 18 20:32:03 2018 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fr614-0008Rr-Td for gnu-bug-gnulib@m.gmane.org; Sat, 18 Aug 2018 20:32:03 +0200 Original-Received: from localhost ([::1]:40049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fr63B-0004I9-DZ for gnu-bug-gnulib@m.gmane.org; Sat, 18 Aug 2018 14:34:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fr630-0004I3-Bu for bug-gnulib@gnu.org; Sat, 18 Aug 2018 14:34:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fr62z-0007Cg-B7 for bug-gnulib@gnu.org; Sat, 18 Aug 2018 14:34:02 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::12]:15972) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fr62y-0007Bq-RN; Sat, 18 Aug 2018 14:34:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1534617239; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=7CXyV5RJziAahzyLCsfvDO/6UCldc285F++3rDWmojU=; b=Kmhi95jejSc+ggiyaHgwqRDb3ilVigzbYtQ2464BcqpHoGKmx9fn3hM+ikt0Cz/d/n bhHw99JQSc86JnBjFhRnX1Sdjc3GKuKQiKQnZacx+5FSewn/ZqOZizRgBEU19spRLeU2 h66NLRrTGu0vzwX4kcSo8ymXLWpvOjpYwXkHDeUHl2x7RWbtjRMg3Tcr7cqYrHPHHBoR ZE7WhuzVvouoWybHFFojPEJ/2iDmk6K5gsIcvycggCw+XIyEjF3uiSy2blb6WNBmk8qt O0V/3HVWCr2ZxyD1XjZZ1dIcb3HYUGOrGwUkWq7EcOC6hsoyoEnoL2t2ZleYV5HphbBf RVEA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf9yfs=" X-RZG-CLASS-ID: mo00 Original-Received: from bruno.haible.de by smtp.strato.de (RZmta 43.18 DYNA|AUTH) with ESMTPSA id n0457au7IIXvLCf (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 18 Aug 2018 20:33:57 +0200 (CEST) In-Reply-To: <0771b7a4-cc93-e23e-0de5-0069ce67a270@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::12 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Original-Sender: "bug-gnulib" Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:39210 gmane.emacs.devel:228662 Archived-At: Paul Eggert wrote: > Can this problem be addressed a bit better by using GetProcAddress only inside > #ifndef HAVE_GETSYSTEMTIMEPRECISEASFILETIME code on builds for MS-Windows 7 and > earlier, and directly using GetSystemTimePreciseAsFileTime on builds for > MS-Windows 8 and later? I don't think the idea of having different builds for different versions of the same operating system is going to fly. - The users can't manage it: Many users don't even know precisely what version of operating system they are running. - The developers don't want it: Why build and test 2 executables if they can achieve the same goal with half of the build and test effort? Also, Emacs builds have pretty strong backward compatibility requirements. I recall that Emacs still supported Windows 2000, when many other packages listed Windows XP as the minimum. As currently ca. 35% of the Windows users still use Windows 7 [1], you can imagine how many years it will take until Emacs binaries don't need to run on Windows 7 any more. Bruno [1] https://windowsreport.com/windows-10-windows-7-popularity/