From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Android port Date: Sun, 06 Aug 2023 18:09:12 +0300 Message-ID: <83h6pcp5rb.fsf@gnu.org> References: <1428589171.162865.1691134964773@mail1.libero.it> <9065382.vXJBWSPEcx@nimes> <83tttcpeof.fsf@gnu.org> <3469960.ipicrQNo7v@nimes> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9442"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org To: Bruno Haible Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 06 17:09:45 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qSfO5-0002Gs-Cj for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Aug 2023 17:09:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSfNK-0006rE-Sc; Sun, 06 Aug 2023 11:08:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSfNK-0006r3-2l for emacs-devel@gnu.org; Sun, 06 Aug 2023 11:08:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSfNI-0000US-JW; Sun, 06 Aug 2023 11:08:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=c3EjQsGyb6jeJvDB5MEHg8g2vK5ZCriYYmb3Q63IZzA=; b=ecokFclDFc/h fKi1Zy4xYEOIr6ug3a707VEwUk5eEWTYysnQ6R6Kbb+hu4mokdImnVSVaSoQNTX2WEvUW3eRJSU48 XAyH1y40xlsweJnn1iv38fs++/ubNfxDYBIKxTDbLBYmaKlsqCGqp815lwVM++8g2TCgjC+T/gJcc 1fVh+9EU5RMq6OfGOM18sVY3D9IgcbfFEwoPKOjDgsJamHoYbEjd7Gn/HBLst0e+YFUSOK8Y6SsP3 81c7lEQrVVepf/omZVyKW1hMI06Jhcyw7s8qbP5EtaypfMeqANnsCI4j6a2G2zPgLkksMkf6qf3lg EUmvDGg3ImIei8h6UUYeIA==; In-Reply-To: <3469960.ipicrQNo7v@nimes> (message from Bruno Haible on Sun, 06 Aug 2023 16:40:10 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308371 Archived-At: > From: Bruno Haible > Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org > Date: Sun, 06 Aug 2023 16:40:10 +0200 > > > The individual gl_cv_* > > variables, if overridden by mingw-cfg.site, will completely shadow the > > feature tests and will from that moment on make detecting any new > > needs for that and dealing with those new needs our responsibility, > > with nothing to aid us. Which in practice means we could have a > > broken port on Windows if some other functionality, which _is_ needed > > on Windows, will become dependent on a test that we've overridden via > > these variables. > > > > Which is why I prefer to disable a module or a function replacement > > without overriding the individual functionality tests which led to the > > inclusion of the module and/or replacement of a function. Disabling > > the module or a function replacement just says that this > > module/function is not needed or is implemented differently, without > > saying anything about the respective functionalities. First, the above is only about the MinGW build of Emacs. We don't override Gnulib tests and their results on any other platforms supported by Emacs and by Gnulib. The reasons for this special treatment of Gnulib on MinGW are: . Emacs supports old versions of Windows while Gnulib dropped their support, so we cannot use Gnulib functions which will fail on those older Windows versions (e.g., because Gnulib assumes some API to be always present which is not available on old Windows versions, or needs to be manually loaded from some DLL); . Emacs supports UTF-8 encoded file names by converting them to UTF-16 and using "wide" APIs to access such file, something Gnulib doesn't support AFAIK, except when the system codepage is UTF-8; . Emacs sometimes have special needs which require emulation of certain APIs in a way that is different from what Gnulib does (examples: getloadavg and ACL functions) With the above in mind: > I'd like to view this question from the process point-of-view: > > If some new functionality test is introduced in gnulib/m4/printf.m4, > be it > (a) because a bug has been discovered on a non-mingw platform > (such as recently the %lc bug), or Not relevant to this discussion: non-MinGW platforms will get what Gnulib provides. > (b) because a bug has been discovered on mingw, or Depends whether this bug is relevant to Emacs, and whether the relevant Gnulib functions are already used in Emacs on Windows. If the latter, we will simply use the updated Gnulib function. Otherwise, it might need changes to Emacs's own code to work around or fix the bug. > (c) because a new ISO C or POSIX standard requires new functionalities > (such as recently the support of %b), If this is needed in Emacs, and in code that is used in the MinGW build, we'd need to wait until __USE_MINGW_ANSI_STDIO will support the new functionality, or provide some workaround in Emacs's code, or declare that the relevant feature doesn't work in the MinGW build. A good example of this is the time-related functions in Emacs: we don't support time-zone specifications of the form "Asia/Seoul" because the Windows time-zone functionality cannot grok that. > Will you typically want to > - review all format strings in Emacs, to see whether they are affected? > - add some note to Emacs-internal coding guidelines, e.g. to the effect > that %b should not be used? > - review the mingw-specific *printf override, to see whether it > needs a workaround (in case b) or an extension (in case c)? > - or do nothing at all? Some mix of the above, depending on the case. But only for the MinGW build. Btw, the problem with printf* is exacerbated because Gnulib pulls in the entire stdio.h when it needs to replace some printf* functionality, and stdio is a huge header/module with some functions that we cannot allow to override in Emacs, due to the aspects I tried to describe above. Fortunately, Emacs needs printf* in only a handful of places, and for very narrow functionality.