Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> 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.