bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0

["Óscar Fuentes" <ofv@wanadoo.es>]

On Onssee
When the macro _FORTIFY_SOURCE > 0, mingw-64 provides an inline
definition of `read` on io.h:

__mingw_bos_extern_ovr
int read(int __fh, void * __dst, unsigned int __n)
{
  return _read(__fh, __dst, __n);
}

*Before* #including io.h, ms-w32.h does

#define read    sys_read

so the inline definition of read above ends like this:

int sys_read(int __fh, void * __dst, unsigned int __n)
{
  return _read(__fh, __dst, __n);
}

As the result of this, the above definition is used instead of Emacs'
definition of sys_read. The resulting Emacs is unusable due to problems
handling subprocesses.

A hack that avoids this consists on doing something like:

#define read dummy_read
// etc
#include <io.h>
// etc
#undef read
#define read sys_read
int sys_read (int, char *, unsigned int);

or simpler but untested:

#define _read sys_read
// etc
#include <io.h>
// etc

Either way it is necessary to condition the hack on the value of
_FORTIFY_SOURCE.

More generally, the way Emacs/NT overrides the CRT functions is
susceptible to break anytime upstream does something like, this case,
adding an inline definition, or some other unanticipated change. AFAIK
the C standard says that precisely what Emacs is doing incurs on
undefined behavior.

Any ideas about how to future-proof the solution for this problem?

BTW, the initial bug report for this was in March 2023 and only today
was succesfully analyzed (1) This gives an idea of how problematic this
practice of redefining standard functions can be.

1. https://github.com/msys2/MINGW-packages/issues/17343#issuecomment-2368903501