From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.comp.lib.gnulib.bugs Subject: Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg Date: Wed, 03 May 2017 18:33:11 +0300 Message-ID: <83o9vagdl4.fsf@gnu.org> References: <20170427222412.28742.14016@vcs0.savannah.gnu.org> <80850259-8972-19b3-6435-2b8b9cc2319b@cs.ucla.edu> <83bmrbi3so.fsf@gnu.org> <3590215.6Xrt2mkima@omega> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1493825636 28370 195.159.176.226 (3 May 2017 15:33:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 May 2017 15:33:56 +0000 (UTC) Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, kbrown@cornell.edu, emacs-devel@gnu.org To: Bruno Haible Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 03 17:33:50 2017 Return-path: Envelope-to: ged-emacs-devel@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 1d5wHl-0007Fo-RD for ged-emacs-devel@m.gmane.org; Wed, 03 May 2017 17:33:49 +0200 Original-Received: from localhost ([::1]:37361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5wHr-0005fn-EI for ged-emacs-devel@m.gmane.org; Wed, 03 May 2017 11:33:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5wHe-0005dl-MI for emacs-devel@gnu.org; Wed, 03 May 2017 11:33:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5wHd-0001kE-Me for emacs-devel@gnu.org; Wed, 03 May 2017 11:33:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5wHX-0001ea-CN; Wed, 03 May 2017 11:33:35 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4247 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d5wHW-00062j-Fa; Wed, 03 May 2017 11:33:34 -0400 In-reply-to: <3590215.6Xrt2mkima@omega> (message from Bruno Haible on Tue, 02 May 2017 23:55:50 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214543 gmane.comp.lib.gnulib.bugs:37225 Archived-At: > From: Bruno Haible > Cc: kbrown@cornell.edu, emacs-devel@gnu.org, bug-gnulib@gnu.org > Date: Tue, 02 May 2017 23:55:50 +0200 > > The patch is fine with me: it has no drawbacks for other packages. Thanks. > However, it would be good to know what qualms you have with the msvc-nothrow > module. Should Emacs be built with mingw, not MSVC? Emacs dropped MSVC support a few years ago. Only MinGW, with its 2 flavors, is currently supported, in addition to Cygwin. Emacs might still build with MSVC, but I don't think anyone tried in a long while, and if they do, they will be in for a ride, because we require the MSYS tools to run the configure script and the Makefiles. > Is an EBADF situation never going to occur in Emacs anyway? It can occur, but AFAIK it cannot cause an exception, since the only supported runtime is msvcrt.dll. > Are the portability efforts for mingw and MSVC > in Gnulib useless for Emacs, because on native Windows Emacs uses its own w32.c > instead anyway? Many features available from Gnulib are indeed independently implemented in w32.c and other Windows-specific files in Emacs. The reasons vary -- some are of historical nature, others because the Emacs implementations are "better" in some sense. The support for non-ASCII file names outside of the current system codepage is a good example of the latter. > Does Emacs have other requirements I don't know about? Some. For example, Emacs cannot use the C runtime functions that manipulate non-ASCII characters, because those are limited to the BMP on Windows, and don't support UTF-8. > Eli Zaretskii wrote: > > That "other way" is the implementation of fdutimens in Emacs's w32.c. > > Perhaps Bruno could look at that implementation and comment on its > > merits and demerits vs the Gnulib implementation > > 1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently assumes > Windows XP at least (and will soon move to Windows 7, I guess - namely when > no one has a test machine with Windows XP any more). Merit or demerit? Opinion? Emacs still tries to support Windows 9X and the NT family members older than XP, yes. But AFAICT, the APIs used in the Gnulib implementation of fdutimens are all supported on Windows 9X. > 2) The Emacs w32.c has an option to use the "W" suffixed Windows APIs by default. > Clearly a merit, because it allows to use file names that are not contained in > the "ANSI codepage". Nowadays users can use (type, display, manipulate) such > file names in the cmd.exe windows; any program which is not on par with this > ability is deficient. In a GUI session, Emacs supports all the Unicode characters, so limiting file names to the current codepage makes even less sense than for console programs running in the cmd window. > 3) The Emacs w32.c fdutimens function handles only 1 second resolution; the > Gnulib fdutimens supports sub-second resolution. I guess we should plan on reimplementing the Emacs version using the more flexible Win32 APIs, to support sub-second resolution. > Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or > ERROR_DEV_NOT_EXIST error code? I don't remember. It's entirely possible that I just looked at the textual representation of these errors and matched the errno values without actually creating the situation. Thanks for the detailed analysis.