On 10/24/21 9:58 AM, Eli Zaretskii wrote:
We could try all that, but not on the release branch. There, I'd like
a simple and safe fix. Is such a thing possible?
Andy suggested a simple fix that I quoted here:
https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
We could apply that patch just to ntlib.c and just in emacs-28 (do not
merge to master) as Andy says that works for him; and we could then
apply the more-systematic patch of
<https://lists.gnu.org/r/emacs-devel/2021-10/msg01697.html> to master.
Andy's patch is definitely safe for GNU and POSIXish hosts. I don't know
whether it suffices for all MS-Windows platforms and Emacs builds.
Can you explain why config.h is needed there, and why only for GCC 11?
config.h is needed because it defines macros used by lib/string.h and
other lib/*.h files that come from Gnulib. I don't know why the problem
occurs only for GCC 11 on MS-Windows platforms, as I would think it'd
also occur with earlier GCC versions. Older GCC versions don't do the
static checking I mentioned, so the macros do not help checking with
older GCC. The macros can safely be #defined to empty as Andy's patch
suggested, so long as config.h isn't included (as it would define them
differently). The downsides of Andy's approach (as compared to the
more-systematic patch) is that you lose out some static checking with
recent GCC, and I worry (without really knowing) that similar problems
may lurk in other MS-Windows-specific .c files on some other MS-Windows
platforms.
