From unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Sep 2024 22:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73444@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17271297536353 (code B ref -1); Mon, 23 Sep 2024 22:16:02 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Sep 2024 22:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.17271306149088 (code B ref 73444); Mon, 23 Sep 2024 22:31:02 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172717870816714 (code B ref 73444); Tue, 24 Sep 2024 11:52:02 +0000 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 In-Reply-To: <87r09axbio.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 00:15:11 +0200) 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 11:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172717874716808 (code B ref 73444); Tue, 24 Sep 2024 11:53:01 +0000 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 In-Reply-To: <87msjyxaum.fsf_-_@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 00:29:37 +0200) 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 12:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172718130525706 (code B ref 73444); Tue, 24 Sep 2024 12:36:01 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 12:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172718259530285 (code B ref 73444); Tue, 24 Sep 2024 12:57:02 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 13:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.17271836111186 (code B ref 73444); Tue, 24 Sep 2024 13:14:02 +0000 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 In-Reply-To: <87ikulxmaz.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 14:34:28 +0200) 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 13:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.17271845014890 (code B ref 73444); Tue, 24 Sep 2024 13:29:01 +0000 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 In-Reply-To: <87ed59xlb7.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 14:55:56 +0200) 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 14:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73444@debbugs.gnu.org, Cyril Arnould Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172718680813879 (code B ref 73444); Tue, 24 Sep 2024 14:07:01 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 15:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 73444@debbugs.gnu.org, cyril.arnould@outlook.com Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.17271922444820 (code B ref 73444); Tue, 24 Sep 2024 15:38:01 +0000 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 In-Reply-To: <87a5fxxi22.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 24 Sep 2024 16:06:13 +0200) 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Sep 2024 10:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Cyril Arnould Cc: 73444@debbugs.gnu.org, Eli Zaretskii Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172725921719594 (code B ref 73444); Wed, 25 Sep 2024 10:14:01 +0000 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 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-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 unknown Sat Sep 06 02:32:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Sep 2024 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73444 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Cyril Arnould Cc: ofv@wanadoo.es, 73444@debbugs.gnu.org Received: via spool by 73444-submit@debbugs.gnu.org id=B73444.172726486011964 (code B ref 73444); Wed, 25 Sep 2024 11:48:02 +0000 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 In-Reply-To: (message from Cyril Arnould on Wed, 25 Sep 2024 00:25:23 +0200) References: X-Spam-Score: -2.3 (--) 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 unknown Sat Sep 06 02:32:42 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: =?UTF-8?Q?=C3=93scar?= Fuentes Subject: bug#73444: closed (Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0) Message-ID: References: <87ikudw29t.fsf@telefonica.net> <87r09axbio.fsf@telefonica.net> X-Gnu-PR-Message: they-closed 73444 X-Gnu-PR-Package: emacs Reply-To: 73444@debbugs.gnu.org Date: Mon, 30 Sep 2024 16:12:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1727712722-5817-1" This is a multi-part message in MIME format... ------------=_1727712722-5817-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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@debbugs.gnu.org. --=20 73444: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73444 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1727712722-5817-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 ------------=_1727712722-5817-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 ------------=_1727712722-5817-1-- From unknown Sat Sep 06 02:32:42 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Cyril Arnould Subject: bug#63752: closed (Re: bug#73444: 30.0.50; mingw-w64: Emacs uses CRT's `read` when _FORTIFY_SOURCE > 0) Message-ID: References: <87ikudw29t.fsf@telefonica.net> X-Gnu-PR-Message: they-closed 63752 X-Gnu-PR-Package: emacs Reply-To: 63752@debbugs.gnu.org Date: Mon, 30 Sep 2024 16:12:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1727712723-5817-3" This is a multi-part message in MIME format... ------------=_1727712723-5817-3 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #73444: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_= FORTIFY_SOURCE 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 63752@debbugs.gnu.org. --=20 73444: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73444 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1727712723-5817-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 ------------=_1727712723-5817-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 27 May 2023 13:02:58 +0000 Received: from localhost ([127.0.0.1]:51530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q2tZQ-0003rt-BD for submit@debbugs.gnu.org; Sat, 27 May 2023 09:02:57 -0400 Received: from lists.gnu.org ([209.51.188.17]:36112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q2tZM-0003rj-My for submit@debbugs.gnu.org; Sat, 27 May 2023 09:02:54 -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 1q2tZM-0005Ho-71 for bug-gnu-emacs@gnu.org; Sat, 27 May 2023 09:02:52 -0400 Received: from mail-vi1eur04olkn0822.outbound.protection.outlook.com ([2a01:111:f400:fe0e::822] helo=EUR04-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2tZJ-0005Dp-EC for bug-gnu-emacs@gnu.org; Sat, 27 May 2023 09:02:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LdT0OiNImqo2fQaQNNh06Bamzlx+oA5Z4y2AQjY8dWY7NYpo8hKEMmcjeU3gC+akXIDXaNasSQvZzuhZqz6Q2cOLLvpLWXQrta7hv4eiWNIBEwM8VytPU1QZPKpbhRYIVg2P0hDKZROIhbGhSKkFKP3WOo4tezZ5Mh6IjC5bOT/OE0VjVHLW0aE1IpPXhOHcj9s5dencQOxlpmb9fKzGaT1i1ZYltI0Kc6aeBDV4DEEeukmJxEXKv1zHpHTi6+Ov/tj5y7d+PSS33TTcRpuBlh09NIYvroRfUBCTOKSIOgK0kJebig0wHPDC5qg7hbeLb381z3nvPo+47Zysy3HW0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rVOlepM8ftJv3yb9AJn1H7ivDJ1QAC4DMgKnibDfNiQ=; b=DkThjzf5U2JkBsyYzH9yFfQl4MyQyyzD0XzCyzKzDLcjJzlY7IFqNgyVCFIK4byPvTWQRG6vK4/tbZHEyw7E4NGJMPFQbdrW5DE3NuQIWJ9W537F3Qqm85AfgiaHqluIJ+vIYsDtr29aQ/WzNakxyX0jJOU37cQqeU8M2+FzuElo92CqPSRMTqKBTGTbqNrxDhHAmMdEhNOeUE6IcEIClvpkYe23KXqBDSjmVdVKOE4ee8cK2pj725o7tdpc/KI6alEj54ud4XaVXUcSXULGmfVCESxD6uu/Am4eO80NBxaHp8SKh10qu1xrZX6b72TB+FkpNLcvQaSC5H/T6yWLKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rVOlepM8ftJv3yb9AJn1H7ivDJ1QAC4DMgKnibDfNiQ=; b=W9KVIJ7oVN1YaNKIVJopIqC6PqKEmsdP1NJ06/ECN0Fu/fH/vfCGmrecrCiN86O9eT7f/RFIeYxwXMhMAOTLzpvrXtFabzmQN4TifGW0g0phDjrBzUA23LcXhn3s8hO4OtT5G9GVnwMVdLWJBuqJAoUPjP+y2tMV66GstsuC85h3Fwz0KheRz1OhqvIL/2i0Np1HSuJ9wi4W9xiL285Aq0BLVhZWsMI+Jz96g+Pr3Tgi1khVYSofJZgNze5Kiut9JVdlQxmrgZ3lKDyXmbS4dcnCWoB8nORE6E8GwpsDBy/2jXrxTYtWoMNrLabIqCoWzTRxiJFv9WmEcSWzbGPYXQ== Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:582::17) by DB8PR10MB3562.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:132::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6433.19; Sat, 27 May 2023 12:57:44 +0000 Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::7a2:effb:6bb7:ada1]) by AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::7a2:effb:6bb7:ada1%7]) with mapi id 15.20.6433.018; Sat, 27 May 2023 12:57:44 +0000 From: Cyril Arnould To: "bug-gnu-emacs@gnu.org" Subject: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE Thread-Topic: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE Thread-Index: AQHZkJpZYgofLGJRxECoonjvgiVqgQ== Date: Sat, 27 May 2023 12:57:44 +0000 Message-ID: Accept-Language: de-CH, en-US Content-Language: de-CH X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [fd8K2Kdzs8I2zVexWiahMRlK/KjBWPMS] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS4PR10MB6110:EE_|DB8PR10MB3562:EE_ x-ms-office365-filtering-correlation-id: d8b198e0-09ce-46ff-4150-08db5eb1f69c x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Taq6cvgMfN5UTM9cREfYCSrZxtkv9LhBX1c1LgWauX++GfrOrHWj9QlU3f6Fl09V95zjGQ4x5DoOo6wkoPA7hD3UqOrkmLjjoMR2Voo51nvQwF4AB9m3Cwo9FTu2IMLVPypo8ZPi/QGCBh/O0rPMbzpzapZYAy3LkXPb55JGKDipYS8OE1Kozn1+E2Qz6eQF5bF/quQ7I5T0K4gDRqYB6N56VdLe9SS1uSh2HLzqvLgjFhIEPGnMloIaYX6LLuYyowqWuEEBCV55ZyAMkvLaphkyXIg3wS88JM0U+JhKqU95BA90VtZKPEnL/ukwbmFgzPi2ZRDOno7rceTadvh27eCoWORLCgTueL3u8fDp70dyLtWXtTG7t/N6xvCWamf/vayWNun1UNeMzmEPUEL2lNQWYVc60npwpiMXItl/oxaXZxcMtxCIQx6a+br8NgqEObnwL7UJWpNV6Qan2hoMb+XZOavo/9zZu7HHhZRPt5l03I9ZoZvHAmC9CTniyyGN5uNPFZccJ+6Gxuuvs7mlYcfdJJBOdE/+HZ8xZbroTwNeOJOjQpsYXa8VycAvSlRNOdPVLLqaQyoFEKlKJCeA5g== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1a+tRZpKfbR2jvrVjhju/mbfvvmfp7Hf1arxj8Y5T1SZebH57EP4YKpqmihm?= =?us-ascii?Q?AmIWJn/3cv+qLtBrgJ4Jf7tz2FOYVVhcVqY5L1dg8wfdo91lM1vAFICArncM?= =?us-ascii?Q?a4wa3bkdcnALA+PrMOU5N+BlmonTAEKuUMLpnvlUNw6Shze+wOGL2EvS//F5?= =?us-ascii?Q?5Y6PVq4Je0FT2TDT0GxZLRU0V2wahc4Wmgvo09divDdJmoDsCRvUjBXF3+3Q?= =?us-ascii?Q?FnOWdAlx+eToLzHoARBIjA8CI5clP5xmG8ENTXjfL6ltW7A3LH6bMTeCZ6Ml?= =?us-ascii?Q?8cjzgXKvjLDfIcFbwssqKDUlqSUUb3czrTGp8S6t8J2AdSCVc9QstDNRJ17H?= =?us-ascii?Q?wCqdI29Agxvt52aZN/3JzulTLtg7uCgH0BCKMKb9Ky/dExyds4xkGAjxYUOY?= =?us-ascii?Q?Gx7mup5El3AfobKt+C5KbnBeXvpZ7mAhMfFH7K/MF3pbxKKO5zNQncGk/rwJ?= =?us-ascii?Q?pJy5nyInKN/Y0+7H8jzflFmJY7bsJhZfUo5g8LR90D+JrPseJ7v9PXo/7kbn?= =?us-ascii?Q?tj2G1WJmIXs71sIVYGbqc0kHMciYoe6oO8LCNCISQUT7mFRrRyS+dE1F7yqF?= =?us-ascii?Q?uqJTMlgx/IIME3LiJ573Aar/js+D2VkMqrEpIfCHT0FpJKosbtcidEPnFnxz?= =?us-ascii?Q?k8/XE4MDo38E7j2ZhGDKqmQwF1Um78HKuNZcLosto3w6zmhW1S1ekIVaJE16?= =?us-ascii?Q?asG7+FIbn7mBG2P/bWKxcuuuWBI3q3VgKlGmhwD5oEWgVabu1ae6L08t5ofU?= =?us-ascii?Q?bT793tpAd0DtlCWeBQ1slMupWN7VoXA4VJpH4WJodxZodLFB/usJpxocVDkG?= =?us-ascii?Q?tEAMiBvoaT5w9+0J2LtTA0skLpbBiiVzP+HtyPb+i09hUx9KMJ8FPsRd/Dc5?= =?us-ascii?Q?0Da5rOLQaZ5yOGXRbT6zS4aApNf9UhmXLHkDSXBuxFrNjKc0RtgjOmix+R6X?= =?us-ascii?Q?6o+yXLy0r/1innYihipnmdB0Fm47DWZAILV7x4AoDMPjo6aTikH3O+qPXo5+?= =?us-ascii?Q?NwNSNnTXLTgOj0b7s7mqKmFRWXevVgMmcHomv3wXo1NyXSfbshNp/J9I3BwC?= =?us-ascii?Q?RdCg7A5LqTxGOMszNCL0y+fJx+NxfF2LOH30kPFOhu2A3N7HQqfmEgunjpOA?= =?us-ascii?Q?ZxP/j7qP07WOxDu/MkiTHEW3PAdY4Z3l6xUN1YxF8o/tMH1Ai0TdDFaRBqXP?= =?us-ascii?Q?MMbSt6fpjip7LcI9n3MMc+eC02axQn1KqUHYCRyUUQpviXKOoVi0OY89VIVe?= =?us-ascii?Q?MH1QFaRyshgOlsxnL3KR?= Content-Type: multipart/alternative; boundary="_000_AS4PR10MB61108173EEBD22AC88ABE125E3449AS4PR10MB6110EURP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: d8b198e0-09ce-46ff-4150-08db5eb1f69c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2023 12:57:44.2416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR10MB3562 Received-SPF: pass client-ip=2a01:111:f400:fe0e::822; envelope-from=cyril.arnould@outlook.com; helo=EUR04-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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 (--) --_000_AS4PR10MB61108173EEBD22AC88ABE125E3449AS4PR10MB6110EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First of all, I'm on Windows 10, using the MINGW64 MSYS2 environment, so this issue might be specific to MinGW. Note: While I'm using a UCRT build of Emacs to generate this report, the problem is present in the MinGW GCC build as well. Emacs has some weird behaviour regarding subprocess handling (?) when compiled with "-D_FORTIFY_SOURCE=3D1". Setting the value to 2 causes the same issue, I haven't tested setting it to 3. I believe this is the why the MSYS2 Emacs builds have been broken for a while now: https://github.com/msys2/MINGW-packages/issues/16190 https://github.com/msys2/MINGW-packages/issues/16375 https://github.com/msys2/MINGW-packages/issues/16413 I've managed to reproduce the issue when building from the emacs sources as follows: git clone https://git.savannah.gnu.org/git/emacs.git cd emacs git checkout emacs-28.2 ./autogen.sh export CFLAGS=3D'-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=3D1' ./configure make "-g3 -O2 -gdwarf-2" were the default compilation options. The build terminates fine but the executable has problems. Executing "dir" via async-shell-command doesn't terminate properly, for example: ./src/emacs -Q --eval '(async-shell-command "dir")' Trying to close the window results in Emacs saying there are active processes, which there shouldn't be. Other symptoms are described in the linked Github issues. In the example above, I built Emacs from the emacs-28.2 tag, but I also managed to reproduce the issue in the emacs-28, emacs-29 and master branches. In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32) of 2023-05-27 built on ZUERILL Repository revision: f31980c83aee3840ee90688447198a37a14f7aaf Repository branch: emacs-28.2 Windowing system distributor 'Microsoft Corp.', version 10.0.19044 System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.2965) Configured using: 'configure --prefix=3D/ucrt64 --host=3Dx86_64-w64-mingw32 --build=3Dx86_64-w64-mingw32 --with-modules --without-dbus --without-compress-install --with-native-compilation 'CFLAGS=3D-march=3Dnocona -msahf -mtune=3Dgeneric -O2 -pipe -fstack-protector-strong' CPPFLAGS=3D-D__USE_MINGW_ANSI_STDIO=3D1 'LDFLAGS=3D-pipe -lpthread'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM ZLIB Important settings: value of $LANG: en_GB locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: display-line-numbers-mode: t override-global-mode: t delete-selection-mode: t tabbar-mwheel-mode: t tabbar-mode: t global-so-long-mode: t global-flycheck-mode: t flycheck-mode: t cua-mode: t company-tng-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: ~/.lisp/load/vhdl-mode hides c:/msys64/ucrt64/share/emacs/28.2/lisp/progmod= es/vhdl-mode Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils display-line-numbers cl-extra use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core server delsel tabbar easy-mmode grep compile text-property-search comint ring so-long flycheck ansi-color find-func help-mode rx dash cua-base company-tng company edmacro kmacro pcase cus-load tex-site info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 161207 53896) (symbols 48 13207 112) (strings 32 43518 8562) (string-bytes 1 1529452) (vectors 16 23546) (vector-slots 8 437343 90008) (floats 8 73 206) (intervals 56 299 290) (buffers 992 11)) --_000_AS4PR10MB61108173EEBD22AC88ABE125E3449AS4PR10MB6110EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First of all, I'm on Windows 10, using the MINGW64 M= SYS2 environment, so

this issue might be specific to MinGW. Note: While I= 'm using a UCRT

build of Emacs to generate this report, the problem = is present in the

MinGW GCC build as well. Emacs has some weird behavi= our regarding

subprocess handling (?) when compiled with

"-D_FORTIFY_SOURCE=3D1". Setting the value= to 2 causes the same issue, I

haven't tested setting it to 3. I believe this is th= e why the MSYS2

Emacs builds have been broken for a while now:

 

https://github.com/msys2/MINGW-packages/issues/16190=

https://github.com/msys2/MINGW-packages/issues/16375=

https://github.com/msys2/MINGW-packages/issues/16413=

 

I've managed to reproduce the issue when building fr= om the emacs

sources as follows:

 

git clone https://git.savannah.gnu.org/git/emacs.git=

cd emacs

git checkout emacs-28.2

./autogen.sh

export CFLAGS=3D'-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SO= URCE=3D1'

./configure

make

 

"-g3 -O2 -gdwarf-2" were the default compi= lation options. The build

terminates fine but the executable has problems. Exe= cuting "dir" via

async-shell-command doesn't terminate properly, for = example:

 

./src/emacs -Q --eval '(async-shell-command "di= r")'

 

Trying to close the window results in Emacs saying t= here are active

processes, which there shouldn't be. Other symptoms = are described in the

linked Github issues.

 

In the example above, I built Emacs from the emacs-2= 8.2 tag, but I also

managed to reproduce the issue in the emacs-28, emac= s-29 and master

branches.

 

 

 

In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)

of 2023-05-27 built on ZUERILL

Repository revision: f31980c83aee3840ee90688447198a3= 7a14f7aaf

Repository branch: emacs-28.2

Windowing system distributor 'Microsoft Corp.', vers= ion 10.0.19044

System Description: Microsoft Windows 10 Pro (v10.0.= 2009.19044.2965)

 

Configured using:

'configure --prefix=3D/ucrt64 --host=3Dx86_64-w64-mi= ngw32

--build=3Dx86_64-w64-mingw32 --with-modules --withou= t-dbus

--without-compress-install --with-native-compilation=

'CFLAGS=3D-march=3Dnocona -msahf -mtune=3Dgeneric -O= 2 -pipe

-fstack-protector-strong' CPPFLAGS=3D-D__USE_MINGW_A= NSI_STDIO=3D1

'LDFLAGS=3D-pipe -lpthread''

 

Configured features:

ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 = MODULES NATIVE_COMP

NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF= TOOLKIT_SCROLL_BARS

XPM ZLIB

 

Important settings:

  value of $LANG: en_GB

  locale-coding-system: cp1252

 

Major mode: Lisp Interaction

 

Minor modes in effect:

  display-line-numbers-mode: t

  override-global-mode: t

  delete-selection-mode: t

  tabbar-mwheel-mode: t

  tabbar-mode: t

  global-so-long-mode: t

  global-flycheck-mode: t

  flycheck-mode: t

  cua-mode: t

  company-tng-mode: t

  tooltip-mode: t

  global-eldoc-mode: t

  eldoc-mode: t

  show-paren-mode: t

  electric-indent-mode: t

  mouse-wheel-mode: t

  menu-bar-mode: t

  file-name-shadow-mode: t

  global-font-lock-mode: t

  font-lock-mode: t

  blink-cursor-mode: t

  auto-composition-mode: t

  auto-encryption-mode: t

  auto-compression-mode: t

  size-indication-mode: t

  column-number-mode: t

  line-number-mode: t

  transient-mark-mode: t

 

Load-path shadows:

~/.lisp/load/vhdl-mode hides c:/msys64/ucrt64/share/= emacs/28.2/lisp/progmodes/vhdl-mode

 

Features:

(shadow sort mail-extr emacsbug message rmc puny dir= ed dired-loaddefs

rfc822 mml mml-sec epa derived epg rfc6068 epg-confi= g gnus-util rmail

rmail-loaddefs time-date mm-decode mm-bodies mm-enco= de mail-parse

rfc2231 mailabbrev gmm-utils mailheader sendmail rfc= 2047 rfc2045

ietf-drums mm-util mail-prsvr mail-utils display-lin= e-numbers cl-extra

use-package use-package-ensure use-package-delight u= se-package-diminish

use-package-bind-key bind-key use-package-core serve= r delsel tabbar

easy-mmode grep compile text-property-search comint = ring so-long

flycheck ansi-color find-func help-mode rx dash cua-= base company-tng

company edmacro kmacro pcase cus-load tex-site info = package browse-url

url url-proxy url-privacy url-expand url-methods url= -history url-cookie

url-domsuf url-util mailcap url-handlers url-parse a= uth-source cl-seq

eieio eieio-core cl-macs eieio-loaddefs password-cac= he json subr-x map

url-vars seq byte-opt gv bytecomp byte-compile cconv= cl-loaddefs cl-lib

iso-transl tooltip eldoc paren electric uniquify edi= ff-hook vc-hooks

lisp-float-type elisp-mode mwheel dos-w32 ls-lisp di= sp-table

term/w32-win w32-win w32-vars term/common-win tool-b= ar dnd fontset image

regexp-opt fringe tabulated-list replace newcomment = text-mode lisp-mode

prog-mode register page tab-bar menu-bar rfn-eshadow= isearch easymenu

timer select scroll-bar mouse jit-lock font-lock syn= tax font-core

term/tty-colors frame minibuffer cl-generic cham geo= rgian utf-8-lang

misc-lang vietnamese tibetan thai tai-viet lao korea= n japanese eucjp-ms

cp51932 hebrew greek romanian slovak czech european = ethiopic indian

cyrillic chinese composite emoji-zwj charscript char= prop case-table

epa-hook jka-cmpr-hook help simple abbrev obarray cl= -preloaded nadvice

button loaddefs faces cus-face macroexp files window= text-properties

overlay sha1 md5 base64 format env code-pages mule c= ustom widget

hashtable-print-readable backquote threads w32notify= w32 lcms2 multi-tty

make-network-process native-compile emacs)

 

Memory information:

((conses 16 161207 53896)

(symbols 48 13207 112)

(strings 32 43518 8562)

(string-bytes 1 1529452)

(vectors 16 23546)

(vector-slots 8 437343 90008)

(floats 8 73 206)

(intervals 56 299 290)

(buffers 992 11))

--_000_AS4PR10MB61108173EEBD22AC88ABE125E3449AS4PR10MB6110EURP_-- ------------=_1727712723-5817-3--