bug#20681: Build failure [MSYS2/MINGW64, OSX]

[Eli Zaretskii]

> Date: Mon, 1 Jun 2015 20:41:02 +0200
> From: Andreas Grünbacher <andreas.gruenbacher@gmail.com>
> Cc: Nick Andryshak <nandryshak@gmail.com>, 20681@debbugs.gnu.org, 
>       Paul Eggert <eggert@cs.ucla.edu>, Angelo Graziosi 
> <angelo.graziosi@alice.it>
> 
> 2015-06-01 19:39 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> > ??? If it were true, set-permissions.c would compile on Windows.  It
> > doesn't.
> 
> I've already explained, at length, why it currently doesn't compile, and
> at least three ways of how it could be fixed.
> 
> > So there's more to this job than just copying the code.
> 
> Yes, adding some #ifdefs and autoconf checks, that kind of thing.
> That's not so hard.

You have just explained at length why using emulation of Posix ACL
APIs would be wrong on Windows, so I assumed that copying the Emacs
implementation with minimal changes into Gnulib must also be wrong in
your opinion.

> >> > There's also the minor (but important for Emacs) point of supporting
> >> > file names with characters outside of the current system codepage,
> >> > which Gnulib can only provide in UTF-8 locales, something that doesn't
> >> > exist on Windows.
> >>
> >> This has nothing to do with get_permissions and set_permissions.
> >
> > It's a reason not to use Gnulib for any file-related operations in
> > Emacs on Windows, because Emacs on Windows uses Unicode APIs to access
> > files by their names.
> 
> So it's okay to have this function in emacs:
> 
>   src/w32.c:acl_get_file (const char *fname, acl_type_t type)
> 
> but the same interface in gnulib wouldn't be okay? Right ...

Emacs on Windows pretends to live in a UTF-8 locale, so file names are
encoded in UTF-8 before they are passed to functions like
acl_get_file; then acl_get_file and other such functions convert the
file names to UTF-16 before calling Windows Unicode APIs.

This works well for Emacs, but Gnulib is not just for Emacs, it is
used by many other projects that build out of the box with MinGW.
Most, if not all, of those projects do NOT pass UTF-8 file names to
library functions, and many of them don't even have facilities that
exist in Emacs to encode file names before calling library functions
-- they simply pass C char * strings to them, which will only work on
Windows if those strings are encoded in the current system codepage.

Therefore, functions that assume UTF-8 encoded file name CANNOT be
added to Gnulib, as they will break every project except Emacs.
Gnulib on Windows _requires_ file names in the system codepage, which
is no longer acceptable for Emacs, because Emacs has broken out of
this limitation several releases ago, and it can now visit files whose
names are not limited to system codepage.

> I'll stop this discussion now, you're just not making sense.

Maybe you should study the subject more deeply, before passing such
judgments.