From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Date: Tue, 24 Sep 2024 14:48:57 +0300 Message-ID: <86setpe0gm.fsf@gnu.org> References: <87r09axbio.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22463"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73444@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 24 13:52:11 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1st45R-0005dn-EK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Sep 2024 13:52:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1st44z-0000UQ-Qx; Tue, 24 Sep 2024 07:51:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1st44w-0000UD-NL for bug-gnu-emacs@gnu.org; Tue, 24 Sep 2024 07:51:39 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1st44w-0007xY-2D for bug-gnu-emacs@gnu.org; Tue, 24 Sep 2024 07:51:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=yW4ludlljc553/yBjL/+9WmkyFIXzXgUeK5hgdVvqPs=; b=Lx39BoEnUs0qLwb8bDsvLbQT2yK9bVzJaKmd1Qc346Dll/bjuC6TeqIszSF9wXae2BnMe4aATzvJZc/6DmiXhFAlAekJaRHtWCKSoVggnSwTa23fIfWNuwEKnYrgL2fCh4ivHSuxbWs67QkAi1UDdRqKOw6h4HpVxaAqVE/lTNRLHdrRe1TDyjJjegdG5BSmdcLi6qU+ueb1pIabb6lHx8Sg3n7EQx1YeZisdDy2MvE7dBUdMEOUzJpz5C+BUN+hM1V+WOckd1X9IKGuGf6EfNCz9FpsW4qXoIeMaZIm/j9Y+Q7W+v+MrIJNyZV11rOEu3UPtsEX1ImM2f5tiBQsuw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1st45K-0004M0-27 for bug-gnu-emacs@gnu.org; Tue, 24 Sep 2024 07:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 11:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs Original-Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172717870816714 (code B ref 73444); Tue, 24 Sep 2024 11:52:02 +0000 Original-Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 11:51:48 +0000 Original-Received: from localhost ([127.0.0.1]:45433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st455-0004LW-KF for submit@debbugs.gnu.org; Tue, 24 Sep 2024 07:51:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st451-0004LA-31 for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 07:51:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1st42Q-0007eG-8w; Tue, 24 Sep 2024 07:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=yW4ludlljc553/yBjL/+9WmkyFIXzXgUeK5hgdVvqPs=; b=CdD0h+l6kz1xbr/mAPHN n9Lxc6bQK2FHj15A2En9MyH6GkCsNS/lfgpDCIw+ef1gp59Mk2nt5RZyde02n6ES+9E35lvMB+BT6 z4a8HwHC2QYTrX2xax5uZSibnJdsevTu51jR4miH3SV7x+E/2c1fSlKdnM1XlIPsjrl8LupzaOO1i i1yv6Ja/yhfOL0M0JsrPTDrldQGBwdiGfEpP0yU5MpKCS9z3SC9dFMWqS1YEVLsxp3FEQ/Or6JfCh wxeaMQDJetFuUZrs3paDzGDx2c2PD4Pdik3JmDtkm8uy8pzO3o3D39ohp0TmI7ZsaLcZ57xRK52NC mA+11EuLQ7hw1w==; In-Reply-To: <87r09axbio.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 00:15:11 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292319 Archived-At: > From: Óscar Fuentes > 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); > } Isn't that a bug in MinGW64's io.h? They should have used __mingw_bos_extern_ovr int (read)(int __fh, void * __dst, unsigned int __n) { return _read(__fh, __dst, __n); } Then we could modify the macro slightly as follows: #define read(h,d,n) sys_read(h,d,n) and avoid the problem. The above is how you protect your functions from being interpreted as macro invocations. But I guess this is water under the bridge now? > A hack that avoids this consists on doing something like: > > #define read dummy_read > // etc > #include > // etc > #undef read > #define read sys_read > int sys_read (int, char *, unsigned int); This indeed needs the prototype for sys_read, which is less desirable, because we lose the ability to have the prototype exactly match io.h without knowing what's in io.h. But I guess there's no better way, sigh... > or simpler but untested: > > #define _read sys_read > // etc > #include > // etc That's simply wrong: we do NOT want to replace the Microsoft '_read', we want to replace the Posix 'read' where it is used by Emacs. > Either way it is necessary to condition the hack on the value of > _FORTIFY_SOURCE. We could do that unconditionally, no? Does the MinGW64 build with _FORTIFY_SOURCE work, after taking care of that? > 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? Not elegant ones, no. We are redirecting Posix functions to our implementations where Emacs expects them to do something the MS runtime doesn't, and we don't want to reproduce all the stuff in the system headers that is related to those functions, including specific data types, symbols, etc. > 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. Trying to make Emacs work well on MS-Windows is problematic in itself, so we shouldn't be surprised it uses some "unconventional" techniques.