bug#45198: 28.0.50; Sandbox mode

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 31 Dec 2020 16:05:52 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Bastien <bzg@gnu.org>, 
> 45198@debbugs.gnu.org, 
>       João Távora <joaotavora@gmail.com>
> 
> Am Di., 29. Dez. 2020 um 18:09 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > Because some/many Gnulib replacements are incompatible with how the
> > w32 port of Emacs works.  In particular, functions which operate on
> > file names don't support UTF-8 encoded file names; Gnulib's 'stat' and
> > 'fstat' don't support security-related features from which we glean
> > owner and group of files; network-related functions need special
> > handling in Emacs to support subprocess functionality; etc.
> 
> That's a fair point, but does the mere presence of these replacements
> really break the build?

If the function compiles cleanly and is not used on MS-Windows, then
no, the build won't break.

> Could we somehow make them not break the build?

It's not up to us, because we don't maintain Gnulib code.  And it
isn't always practical, since the Windows port of Emacs has its own
replacements for some Posix functionality that conflict with the
Gnulib replacements.

> > I know; I wrote that.  However, this talks about code that will be
> > actually _used_ in the Windows build, whereas here we are talking
> > about "ballast": the related code will not be used at all.  So it
> > makes sense not to make our job harder by adding unnecessary code,
> > which then will need to be audited for compatibility.  Your Gnulib
> > import adds quite a lot of modules, which makes the audit a large job.
> 
> Independent of this discussion, are there ways to reduce the size of
> the auditing job? I'd hope that eventually the only thing needed would
> be to run the test suite (which ideally would happen automatically on
> Gitlab/Emba).

The test suite is doesn't yet have enough coverage.  And if Emacs
fails to build, the test suite cannot help.

> For developers not on Windows, it's unfortunately difficult to predict
> whether a specific change will break the Windows build or not, and the
> large difference between the Windows and other builds doesn't make
> this easier.

Sure, that's when posting a patch or a separate branch are a good
means to let the code be fixed before it lands.