From unknown Sat Sep 06 02:33:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#73444 <73444@debbugs.gnu.org> To: bug#73444 <73444@debbugs.gnu.org> Subject: Status: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Reply-To: bug#73444 <73444@debbugs.gnu.org> Date: Sat, 06 Sep 2025 09:33:10 +0000 retitle 73444 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOU= RCE > 0 reassign 73444 emacs submitter 73444 =C3=93scar Fuentes severity 73444 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 18:15:53 2024 Received: (at submit) by debbugs.gnu.org; 23 Sep 2024 22:15:53 +0000 Received: from localhost ([127.0.0.1]:44844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrLV-0001eP-Bk for submit@debbugs.gnu.org; Mon, 23 Sep 2024 18:15:53 -0400 Received: from lists.gnu.org ([209.51.188.17]:34990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrLT-0001eI-Iq for submit@debbugs.gnu.org; Mon, 23 Sep 2024 18:15:52 -0400 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 1ssrL5-00019p-Q2 for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 18:15:27 -0400 Received: from relayout02.e.movistar.es ([86.109.101.202] helo=relayout02-redir.e.movistar.es) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssrL2-0001kW-My for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 18:15:27 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XCHNw14n0zdZRN for ; Tue, 24 Sep 2024 00:15:11 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: bug-gnu-emacs@gnu.org Subject: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 X-Debbugs-Cc: Date: Tue, 24 Sep 2024 00:15:11 +0200 Message-ID: <87r09axbio.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XCHNw14n0zdZRN.A2540 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727734514.24166@3SgkCIFAZy2NKYxyL+oqIQ X-Spam-Status: No Received-SPF: softfail client-ip=86.109.101.202; envelope-from=ofv@wanadoo.es; helo=relayout02-redir.e.movistar.es X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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 // etc #undef read #define read sys_read int sys_read (int, char *, unsigned int); or simpler but untested: #define _read sys_read // etc #include // 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 18:30:14 2024 Received: (at 73444) by debbugs.gnu.org; 23 Sep 2024 22:30:14 +0000 Received: from localhost ([127.0.0.1]:44870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrZO-0002MU-CH for submit@debbugs.gnu.org; Mon, 23 Sep 2024 18:30:14 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:23491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrZL-0002Kz-Vu for 73444@debbugs.gnu.org; Mon, 23 Sep 2024 18:30:13 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XCHjZ1Yy4zdbg7 for <73444@debbugs.gnu.org>; Tue, 24 Sep 2024 00:29:37 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: 73444@debbugs.gnu.org Subject: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: (GNU bug Tracking System's message of "Mon, 23 Sep 2024 22:16:02 +0000") References: <87r09axbio.fsf@telefonica.net> Date: Tue, 24 Sep 2024 00:29:37 +0200 Message-ID: <87msjyxaum.fsf_-_@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XCHjZ1Yy4zdbg7.A865C X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727735379.61275@M/V9rNqj9yo5Iv3PeH1gNg X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73444 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) BTW, #63752 was filed about the observable problems when Emacs is built with _FORTIFY_SOURCE on mingw-w64, which documents an ensuing effort to try to identify the cause, unsuccessfully. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 07:51:48 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 11:51:48 +0000 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 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 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==; Date: Tue, 24 Sep 2024 14:48:57 +0300 Message-Id: <86setpe0gm.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-Reply-To: <87r09axbio.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 00:15:11 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: <87r09axbio.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 07:52:27 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 11:52:27 +0000 Received: from localhost ([127.0.0.1]:45438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st45j-0004N2-3d for submit@debbugs.gnu.org; Tue, 24 Sep 2024 07:52:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st45h-0004Mn-C7 for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 07:52:25 -0400 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 1st45D-0007zJ-F3; Tue, 24 Sep 2024 07:51:55 -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=UF2DjPTg76XcjCTvo7dT1uajoMseATI5+prfgnJpEMQ=; b=mt/HIuDdP/Igm8QWSo43 248UykqGIF/kqFGGU6/v40kw0pkB1aQY/EC/JdVjCvoOLYeKUlLkeRd6VSXg4fzCIRo2kgIKXGQuD jNG5aLDQMgH8L48LMGHJKwLDx3HuvLVT3PEt6nvSl2lzHyYVvG6JRr3V06x+qJ+VxzmlIhN6zRjjy p0RKGp3WMkbr0amL2CdHT40QFx7DXTJcLVYSFFrSiVkPGxoWBQGaziG7tGgaWC09JnY1y0Hc718wR yUAgdibRBPEYBPhOD4rOFhEYSdjEF3Tj3bVRXK3P9w+Wy4+053lCWXfhZtgWWHDivcI4bzqYIa0yN jsJuRRWh3LmWQg==; Date: Tue, 24 Sep 2024 14:51:52 +0300 Message-Id: <86r099e0br.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-Reply-To: <87msjyxaum.fsf_-_@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 00:29:37 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: <87r09axbio.fsf@telefonica.net> <87msjyxaum.fsf_-_@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Date: Tue, 24 Sep 2024 00:29:37 +0200 > > BTW, #63752 was filed about the observable problems when Emacs is built > with _FORTIFY_SOURCE on mingw-w64, which documents an ensuing effort to > try to identify the cause, unsuccessfully. I don't think I follow. Are you saying that these two bugs should be merged, because solving this problem with 'read' solves also the problems reported in bug#63752? Or are there other problems with _FORTIFY_SOURCE that are still left unresolved if the issue with 'read' is fixed? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 08:35:05 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 12:35:05 +0000 Received: from localhost ([127.0.0.1]:45530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st4kz-0006gX-B2 for submit@debbugs.gnu.org; Tue, 24 Sep 2024 08:35:05 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:53679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st4kv-0006fu-RE for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 08:35:04 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XCfSP3TWbzdcLK; Tue, 24 Sep 2024 14:34:28 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Eli Zaretskii Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: <86r099e0br.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Sep 2024 14:51:52 +0300") References: <87r09axbio.fsf@telefonica.net> <87msjyxaum.fsf_-_@telefonica.net> <86r099e0br.fsf@gnu.org> Date: Tue, 24 Sep 2024 14:34:28 +0200 Message-ID: <87ikulxmaz.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XCfSP3TWbzdcLK.A8AFD X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727786071.83297@VzbvXvxHnVaDgm6SwNoPXw X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> From: =C3=93scar Fuentes >> Date: Tue, 24 Sep 2024 00:29:37 +0200 >>=20 >> BTW, #63752 was filed about the observable problems when Emacs is built >> with _FORTIFY_SOURCE on mingw-w64, which documents an ensuing effort to >> try to identify the cause, unsuccessfully. > > I don't think I follow. Are you saying that these two bugs should be > merged, because solving this problem with 'read' solves also the > problems reported in bug#63752? Or are there other problems with > _FORTIFY_SOURCE that are still left unresolved if the issue with > 'read' is fixed? #63752 describes the simptons and tries to identify the cause, this bug (#73444) provides the cause and discusses a possible fix, hopefully one that covers the general case and not just `read'. I was not aware of the existence of #63752 when I created this bug. As what to do with #63752, I have no preferences. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 08:56:35 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 12:56:35 +0000 Received: from localhost ([127.0.0.1]:45539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st55l-0007sO-Q7 for submit@debbugs.gnu.org; Tue, 24 Sep 2024 08:56:34 -0400 Received: from relayout03.e.movistar.es ([86.109.101.203]:25505 helo=relayout03-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st55g-0007s3-95 for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 08:56:32 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout03.e.movistar.es (Postfix) with ESMTPSA id 4XCfx940NgzMmb9; Tue, 24 Sep 2024 14:55:56 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Eli Zaretskii Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: <86setpe0gm.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Sep 2024 14:48:57 +0300") References: <87r09axbio.fsf@telefonica.net> <86setpe0gm.fsf@gnu.org> Date: Tue, 24 Sep 2024 14:55:56 +0200 Message-ID: <87ed59xlb7.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout03 X-TnetOut-MsgID: 4XCfx940NgzMmb9.A71B5 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727787358.1044@owNSoYU+7cxvg9fMRdOQyw X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> From: =C3=93scar Fuentes >> Date: Tue, 24 Sep 2024 00:15:11 +0200 >>=20 >>=20 >> On Onssee >> When the macro _FORTIFY_SOURCE > 0, mingw-64 provides an inline >> definition of `read` on io.h: >>=20 >> __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. Well, AFAIK we are not supposed to #define names on the CRT namespace. > But I guess this is water under the bridge now? Yep, so discussing this is moot. >> A hack that avoids this consists on doing something like: >>=20 >> #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: >>=20 >> #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. Ok. >> 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? I tested that Emacs/MinGW64 + _FORTIFY_SOURCE works with the #define read dummy_read hack. Once we put the prototype for sys_read on ms-w32.h, maybe there is no need to put a conditional on _FORTIFY_SOURCE as well. I can check 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. >>=20 >> 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. Indeed. I was hoping for a trick from some of you C wizards. So, ok to install the workaround? On which branch? 1 file changed, 6 insertions(+), 1 deletion(-) nt/inc/ms-w32.h | 7 ++++++- modified nt/inc/ms-w32.h @@ -257,7 +257,7 @@ extern void w32_reset_stack_overflow_guard (void); #define link sys_link #define localtime sys_localtime #undef read -#define read sys_read +#define read unwanted_read // Override the CRT read, see #73444 #define rename sys_rename #define rmdir sys_rmdir #define select sys_select @@ -380,6 +380,11 @@ extern struct tm *localtime_r (time_t const * restrict= , struct tm * restrict); #define fileno _fileno #endif =20 +// Here we override CRT read with our own, see #73444 +#undef read +#define read sys_read +int sys_read (int, char *, unsigned int); + /* Defines that we need that aren't in the standard signal.h. */ #define SIGHUP 1 /* Hang up */ #define SIGQUIT 3 /* Quit process */ From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 09:13:30 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 13:13:31 +0000 Received: from localhost ([127.0.0.1]:45544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st5MA-0000J4-Ds for submit@debbugs.gnu.org; Tue, 24 Sep 2024 09:13:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st5M5-0000Im-Vd for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 09:13:28 -0400 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 1st5LL-0001fB-Iv; Tue, 24 Sep 2024 09:12:48 -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=Yprm8UIgC+5c7UB+vgQRozeDSfant3MD9SFZHfTM2OY=; b=jVpM9CfgyMbjtIurVN6e 4jFAHNgb3y2lQUSs+iAUjaDitYQRdvOQGLUC2V1Y1COmIC0R/EM73zNT8jfaA7IeXgam0NAgYXLBo 0okgnMgdvKBSnoAcdsJtK8TFElkh3yv5oDJvkMMnpjM8RgWo69gQVe2xeh0hEQAuzOi9jFhDTqxUT P+5C5C7ZwdaTdSq2egok5VbgC2yahdy7ZHh9cB+2jC6aaRa185UtCygArDj4TS7+xH3/XCQdbQxc1 0UivOzPEY43TkTdi3lJAyslchTDTimNJIbRAzVL4Rb937rU63dXnhNjNUI+JHm793aVn+xeoTj0t0 tpzTmXDKUfbuPg==; Date: Tue, 24 Sep 2024 16:12:35 +0300 Message-Id: <868qvhdwl8.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-Reply-To: <87ikulxmaz.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 14:34:28 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: <87r09axbio.fsf@telefonica.net> <87msjyxaum.fsf_-_@telefonica.net> <86r099e0br.fsf@gnu.org> <87ikulxmaz.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 73444@debbugs.gnu.org > Date: Tue, 24 Sep 2024 14:34:28 +0200 > X-Spam-Status: No > > Eli Zaretskii writes: > > >> From: Óscar Fuentes > >> Date: Tue, 24 Sep 2024 00:29:37 +0200 > >> > >> BTW, #63752 was filed about the observable problems when Emacs is built > >> with _FORTIFY_SOURCE on mingw-w64, which documents an ensuing effort to > >> try to identify the cause, unsuccessfully. > > > > I don't think I follow. Are you saying that these two bugs should be > > merged, because solving this problem with 'read' solves also the > > problems reported in bug#63752? Or are there other problems with > > _FORTIFY_SOURCE that are still left unresolved if the issue with > > 'read' is fixed? > > #63752 describes the simptons and tries to identify the cause, this bug > (#73444) provides the cause and discusses a possible fix, hopefully one > that covers the general case and not just `read'. The fix posted here affects only 'read', unless I'm missing something... > I was not aware of the existence of #63752 when I created this bug. As > what to do with #63752, I have no preferences. That's okay. If you tell that fixing the issue with 'read' solves the problem described in bug#63752, I will merge them. But if some problems caused by _FORTIFY_SOURCE still remain after fixing 'read', then bug#63752 is more general, and I think they should remain separate, so that when we close this one, the other one stays open. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 09:28:20 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 13:28:21 +0000 Received: from localhost ([127.0.0.1]:45555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st5aW-0001Go-F8 for submit@debbugs.gnu.org; Tue, 24 Sep 2024 09:28:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st5aR-0001GV-64 for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 09:28:18 -0400 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 1st5Zw-0003HG-Nz; Tue, 24 Sep 2024 09:27:44 -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=tNSXPgmRNA+FUL53jTszUjg5sH6RZ3u1QpWUN+YxnSk=; b=eHUnUrcfAxjV9RfjKzqg KmPtDT/9YsyLOoqc8HYwaxERK7tIlZ4VyD5V4WMQaKNlkgSXRP16Dp6IS8xUeM8kFNwjWhFbS5ulR LsG4L/2uZGAvAkm8Jne4RKdFxOHEYxOESTjqfRJxiJXX6dtdiryQQBNdByXNUqL0MY3XXyyN1emCM 4C2fmRobQ5RuXWEa53TyuxxO340ooZ7luB9OwQXNwAs1BwzZqeYjJvJur7qtCes1ftnzA++3Q8h4u bKvgcRJB0P1Y8LznbKWyM3PY4aNbJAAW/GSpH18O8KprYU6qeQb3D5nv1aEKwrdBfP2dwUieCaFBm g/E4pLc9tuWdbw==; Date: Tue, 24 Sep 2024 16:27:39 +0300 Message-Id: <865xqldvw4.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-Reply-To: <87ed59xlb7.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 14:55:56 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: <87r09axbio.fsf@telefonica.net> <86setpe0gm.fsf@gnu.org> <87ed59xlb7.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 73444@debbugs.gnu.org > Date: Tue, 24 Sep 2024 14:55:56 +0200 > > I tested that Emacs/MinGW64 + _FORTIFY_SOURCE works with the > > #define read dummy_read > > hack. Once we put the prototype for sys_read on ms-w32.h, maybe there is > no need to put a conditional on _FORTIFY_SOURCE as well. I can check > that. Yes, I'd like to avoid the _FORTIFY_SOURCE conditional, so that this code is always used. > So, ok to install the workaround? On which branch? On master, please. > @@ -257,7 +257,7 @@ extern void w32_reset_stack_overflow_guard (void); > #define link sys_link > #define localtime sys_localtime > #undef read > -#define read sys_read > +#define read unwanted_read // Override the CRT read, see #73444 > #define rename sys_rename > #define rmdir sys_rmdir > #define select sys_select > @@ -380,6 +380,11 @@ extern struct tm *localtime_r (time_t const * restrict, struct tm * restrict); > #define fileno _fileno > #endif > > +// Here we override CRT read with our own, see #73444 > +#undef read > +#define read sys_read > +int sys_read (int, char *, unsigned int); > + > /* Defines that we need that aren't in the standard signal.h. */ > #define SIGHUP 1 /* Hang up */ > #define SIGQUIT 3 /* Quit process */ But please don't use "//" as comment style, and please don't forget mentioning the bug number in the commit log message. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 10:06:48 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 14:06:48 +0000 Received: from localhost ([127.0.0.1]:46526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st6Bk-0003bn-CL for submit@debbugs.gnu.org; Tue, 24 Sep 2024 10:06:48 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:16371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st6Bi-0003bY-1g for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 10:06:47 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XChVG2DJDzdZdZ; Tue, 24 Sep 2024 16:06:14 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Eli Zaretskii Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: <868qvhdwl8.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Sep 2024 16:12:35 +0300") References: <87r09axbio.fsf@telefonica.net> <87msjyxaum.fsf_-_@telefonica.net> <86r099e0br.fsf@gnu.org> <87ikulxmaz.fsf@telefonica.net> <868qvhdwl8.fsf@gnu.org> Date: Tue, 24 Sep 2024 16:06:13 +0200 Message-ID: <87a5fxxi22.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XChVG2DJDzdZdZ.A6B18 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727791575.94844@LJLWcE3L+Nr2Pwpu0xKOdw X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org, Cyril Arnould X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> #63752 describes the simptons and tries to identify the cause, this bug >> (#73444) provides the cause and discusses a possible fix, hopefully one >> that covers the general case and not just `read'. > > The fix posted here affects only 'read', unless I'm missing > something... Well, if we could think of a general fix that prevents a potential problem with the other functions that Emacs redefines, I could try to implement it. >> I was not aware of the existence of #63752 when I created this bug. As >> what to do with #63752, I have no preferences. > > That's okay. If you tell that fixing the issue with 'read' solves the > problem described in bug#63752, I will merge them. But if some > problems caused by _FORTIFY_SOURCE still remain after fixing 'read', > then bug#63752 is more general, and I think they should remain > separate, so that when we close this one, the other one stays open. AFAIK the workaround on this bug report fixes #63752. CCing the original bug reporter, just in case. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 11:37:24 2024 Received: (at 73444) by debbugs.gnu.org; 24 Sep 2024 15:37:24 +0000 Received: from localhost ([127.0.0.1]:49692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st7bQ-0001Fe-0V for submit@debbugs.gnu.org; Tue, 24 Sep 2024 11:37:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st7bM-0001FA-64 for 73444@debbugs.gnu.org; Tue, 24 Sep 2024 11:37:22 -0400 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 1st7ao-0005Dn-9A; Tue, 24 Sep 2024 11:36:48 -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=62ATpP4K1KiPiePaP14K3UO+0WxYUnPiY6PbRR+GY3k=; b=pLwgj+rvsbnBkPqJ90bq j7u2+0XbhfAeDH+AQVyo6ji884qK/HIFSoise8FsE0lF2D/OQy9aRqfLVDyYGsIYnb07bSfUWEIhG Di0tGFP4tMOZ1Mspxr1tPvualNPNcMaG2a0fN1sJs5xfN8DsAJCJZE8EG7iC5a3qom2AH1SkRDPuY l8PtUpEYYgRcu72xb687T1eGZGZphpbuTwHhQ1+fR7r3/thxIAJYtcgxHnMGVwDwawS3u2SeZAAOA ew3ncp+3f6or5u4wzo7qQzDkDNJ7fRmtvomQkqt/8Ojz4wHSQYCkXrGBPSWpqUhPOE3kMtunfza3q popy1mcyT1pQug==; Date: Tue, 24 Sep 2024 18:36:37 +0300 Message-Id: <86wmj1cbcq.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-Reply-To: <87a5fxxi22.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 16:06:13 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: <87r09axbio.fsf@telefonica.net> <87msjyxaum.fsf_-_@telefonica.net> <86r099e0br.fsf@gnu.org> <87ikulxmaz.fsf@telefonica.net> <868qvhdwl8.fsf@gnu.org> <87a5fxxi22.fsf@telefonica.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org, cyril.arnould@outlook.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Óscar Fuentes > Cc: 73444@debbugs.gnu.org, Cyril Arnould > Date: Tue, 24 Sep 2024 16:06:13 +0200 > X-Spam-Status: No > > Eli Zaretskii writes: > > >> #63752 describes the simptons and tries to identify the cause, this bug > >> (#73444) provides the cause and discusses a possible fix, hopefully one > >> that covers the general case and not just `read'. > > > > The fix posted here affects only 'read', unless I'm missing > > something... > > Well, if we could think of a general fix that prevents a potential > problem with the other functions that Emacs redefines, I could try to > implement it. AFAIR, that's a very large job, because each redirected function has its own story. If you have time to work on that, please do, but I'd consider this low priority unless there are known problems with specific functions we redirect. > >> I was not aware of the existence of #63752 when I created this bug. As > >> what to do with #63752, I have no preferences. > > > > That's okay. If you tell that fixing the issue with 'read' solves the > > problem described in bug#63752, I will merge them. But if some > > problems caused by _FORTIFY_SOURCE still remain after fixing 'read', > > then bug#63752 is more general, and I think they should remain > > separate, so that when we close this one, the other one stays open. > > AFAIK the workaround on this bug report fixes #63752. CCing the original > bug reporter, just in case. Thanks, I will wait for a while and merge if no objections or comments to the contrary arise. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 25 06:13:37 2024 Received: (at 73444) by debbugs.gnu.org; 25 Sep 2024 10:13:37 +0000 Received: from localhost ([127.0.0.1]:53478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stP1c-00055w-SJ for submit@debbugs.gnu.org; Wed, 25 Sep 2024 06:13:37 -0400 Received: from relayout04-redir.e.movistar.es ([86.109.101.204]:55241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stP1b-00055c-3R for 73444@debbugs.gnu.org; Wed, 25 Sep 2024 06:13:35 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout04.e.movistar.es (Postfix) with ESMTPSA id 4XDCGl0s4Dz16LLZ; Wed, 25 Sep 2024 12:13:02 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Cyril Arnould Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: (Cyril Arnould's message of "Wed, 25 Sep 2024 00:25:23 +0200") References: Date: Wed, 25 Sep 2024 12:13:02 +0200 Message-ID: <87v7ykvy6p.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout04 X-TnetOut-MsgID: 4XDCGl0s4Dz16LLZ.A13A5 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1727863983.83183@620j7qGQIe3jIE3Li7S3QA X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73444 Cc: 73444@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Cyril Arnould writes: > I've tested the workaround applied to master and AFAICT it fixes > #63752. Emacs > was pretty much unusable throughout in the bugged build, with the workaround > it behaves normally. Thanks for testing. I will apply the workaround with the adjustments requested by Eli. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 25 07:47:40 2024 Received: (at 73444) by debbugs.gnu.org; 25 Sep 2024 11:47:40 +0000 Received: from localhost ([127.0.0.1]:57694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stQUd-00036t-Tq for submit@debbugs.gnu.org; Wed, 25 Sep 2024 07:47:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stQUc-00036Z-2N; Wed, 25 Sep 2024 07:47:38 -0400 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 1stQU6-00086t-CR; Wed, 25 Sep 2024 07:47:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1ek5stX89AsxdTaQd4Ii42KrIpKFGT9hHYQTZjMGUSQ=; b=dNeOAL/jvwsw kAMep9TVNM8VRgkuQegtKbh1pJRJncwuKb/T/pGvgBi3aF+3NADQUGCe7mEpfw12glbm46WbnW2oS KFu6p3tEAoLKB1Y3aBBYibq2Z+jEl9CpUH5Z82K+eRmrfB/CoiGaP+HPvl4SPC5PqvNA8cruogVM2 dY4HlGKrPV48/gdF30oJVSV8D4mStbUGzbdypoMBedrPTX99PDVa9LBC8CJQnzKaFJmhmkjMCiT6G uyMgoDBGIa2UDGbia9OLQGU5342pRBF82Xiiqe7pVjNje99uKDRXdHcb9qf3CnHzpz8dfsxaUUi1c /oZzsEQ3DCQSIt7P52GwwA==; Date: Wed, 25 Sep 2024 14:46:47 +0300 Message-Id: <86h6a4c5w8.fsf@gnu.org> From: Eli Zaretskii To: Cyril Arnould In-Reply-To: (message from Cyril Arnould on Wed, 25 Sep 2024 00:25:23 +0200) Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73444 Cc: ofv@wanadoo.es, 73444@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) merge 73444 63752 thanks > Date: Wed, 25 Sep 2024 00:25:23 +0200 > Cc: Eli Zaretskii > From: Cyril Arnould > > > AFAIK the workaround on this bug report fixes #63752. CCing the original > > bug reporter, just in case. > > I've tested the workaround applied to master and AFAICT it fixes #63752. > Emacs > was pretty much unusable throughout in the bugged build, with the workaround > it behaves normally. Thanks, I'm therefore merging these two bugs. P.S. Please in the future keep the bug address on the CC list. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 12:11:21 2024 Received: (at 73444-done) by debbugs.gnu.org; 30 Sep 2024 16:11:21 +0000 Received: from localhost ([127.0.0.1]:45660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIzY-0001V0-WA for submit@debbugs.gnu.org; Mon, 30 Sep 2024 12:11:21 -0400 Received: from relayout02-redir.e.movistar.es ([86.109.101.202]:31739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIzW-0001Ut-NC for 73444-done@debbugs.gnu.org; Mon, 30 Sep 2024 12:11:19 -0400 Received: from sky (132.red-81-39-22.dynamicip.rima-tde.net [81.39.22.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XHQz26rSgzdbqp; Mon, 30 Sep 2024 18:10:38 +0200 (CEST) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: 73444-done@debbugs.gnu.org Subject: Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 In-Reply-To: <865xqldvw4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Sep 2024 16:27:39 +0300") References: <87r09axbio.fsf@telefonica.net> <86setpe0gm.fsf@gnu.org> <87ed59xlb7.fsf@telefonica.net> <865xqldvw4.fsf@gnu.org> Date: Mon, 30 Sep 2024 18:10:38 +0200 Message-ID: <87ikudw29t.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.132 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XHQz26rSgzdbqp.ADD38 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1728317440.13613@dis6CBK+Y27n1QQa/a94gQ X-Spam-Status: No X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 73444-done Cc: Eli Zaretskii , Cyril Arnould X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Fixed in master with commit e376a27cf27d453f3b1c2728626950d4c4478f48 From unknown Sat Sep 06 02:33:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 29 Oct 2024 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator