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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Óscar Fuentes <ofv <at> wanadoo.es>
Subject: bug#73444: closed (Re: bug#73444: 30.0.50; mingw-w64: Emacs uses
 CRT's `read` when _FORTIFY_SOURCE > 0)
Date: Mon, 30 Sep 2024 16:12:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 73444 <at> debbugs.gnu.org.

-- 
73444: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73444
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: 73444-done <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Cyril Arnould <cyril.arnould <at> outlook.com>
Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when
 _FORTIFY_SOURCE > 0
Date: Mon, 30 Sep 2024 18:10:38 +0200

Fixed in master with commit e376a27cf27d453f3b1c2728626950d4c4478f48

[Message part 3 (message/rfc822, inline)]

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0
Date: Tue, 24 Sep 2024 00:15:11 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.