bug#45198: 28.0.50; Sandbox mode

[Philipp Stephani]

Am Di., 29. Dez. 2020 um 16:44 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > It would be great if someone could test whether the Windows build
> > still works after that, thanks!
>
> I only skimmed the changes, but I'm already quite sure they will break
> the Windows build.

Why? Everything should be behind ifdefs/conditional compilation,
otherwise compilation on macOS would also break.

>
> This feature is not relevant to the MS-Windows build of Emacs, at
> least currently (I don't think Windows implements equivalent features
> in a way that is even remotely similar to GNU/Linux).  So to make sure
> the Windows port doesn't break, we must take every measure to avoid
> compiling any of the related code on MS-Windows.  In particular:
>
>   . Gnulib modules pulled to support seccomp should be disabled in the
>     MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
>     nt/gnulib-cfg.mk; and

This shouldn't be necessary, as Gnulib is compatible with Windows (I
guess, since we use it elsewhere), and the MS C library provides an
emulation layer for some parts of the POSIX API (e.g. file
descriptors). OTOH, conditional compilation incurs a maintenance cost,
so we should avoid it if possible.
(That's also what gnulib-cfg.mk says: "In general, do NOT omit modules
that don't need to be omitted, to minimize the differences from
upstream gnulib.mk and thus make the maintenance easier.")

>   . header files used to support seccomp code should be #ifdef'ed by
>     HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed
>     for seccomp and unnecessary otherwise.

That should already be the case.
Turning the question around: is building the branch on Windows
actually broken? If so, what are the error messages?

>
> Btw, I wonder why you needed to import the read-file module from
> Gnulib -- does it provide any features that we couldn't implement on
> our own?  I'm asking because that module caused you to pull in quite a
> few dependency modules from Gnulib, and I'm asking myself whether that
> is really justified.

We could implement it ourselves, if we wanted, and in an earlier
version of the code I did that. But it's easier and less error-prone
to reuse an existing library.