From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Quang Kien Nguyen Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Wed, 7 Aug 2024 16:14:46 -0700 Message-ID: References: <86h6bxq3p3.fsf@gnu.org> <86sevho61y.fsf@gnu.org> <86ed70o90k.fsf@gnu.org> <871q30t8mh.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 08 06:38:34 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sbuv3-000AST-SC for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Aug 2024 06:38:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbuub-0006Wf-Jl; Thu, 08 Aug 2024 00:38:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbps1-0002H7-E8 for emacs-devel@gnu.org; Wed, 07 Aug 2024 19:15:05 -0400 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sbpry-0003Qc-CE; Wed, 07 Aug 2024 19:15:04 -0400 Original-Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a7d2a9a23d9so43703566b.3; Wed, 07 Aug 2024 16:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723072499; x=1723677299; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KhsWi1HArS6xxLNHpVhKBCkL99upJyGRwiGzCz6eWqc=; b=ELJojTHiSQ37HUEC7HDcR7o9B6d5rmTrEco0+XDuL61G3VKebKYXsksI37YpONI2yX rwskX8JXOWoC+WRNpsGVOqaO9q4zkIfegXSx3f3j7rT4EvZoZY9Y5oSenq2iM23gt7KT BeiwmCF5JPJVcs6hKk07ZLuiwtZNi64CYlJRRa5MNw2UPO9zrg2xhlN2zHho+/Z7gG1N ITo2mwNCe1Y6wV8QSTJSdLYZSChiTCno9CU2SX46S6w9HtOV1eyfzS2Qwx39G1fhbT5R wYwTw1g7jcqCaCxn7IwA247AEtZ+CampCc4jf2IA/W6Wn7Y+myS1RoMAADWF2pUSb2WF /K/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723072499; x=1723677299; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KhsWi1HArS6xxLNHpVhKBCkL99upJyGRwiGzCz6eWqc=; b=gN841qc0Exm+cqRaJFxQGMs83YRDS2Q1d56nSa3yeczeCOwbNjRfnhkQ5rt3b9EABm JBp2uYBjVnDl6Yd8nkQH7W3ROo0uRcKdzPtRYJMGOtjJXvMZVXfFCzZFsOthyukjPYDb hABEolw3+d9D9aTa/cGvT8b/kbH7OBxRizwfNPXuwNauwHghZJ/bUDzawTtmkFzsbJoW BdulXGKjQftv2ILpx9OEHaLyRjoiVGP3fSvD/6+T6414Sex3RGF6lYQ7CE7Htau0oV8a F0pJZfvgMA9jKPr92AMvYMw1tLSoiZ1Ep4ASFFMXL09jXM4cZCPkokUohykZF/ph+JxE /vEA== X-Forwarded-Encrypted: i=1; AJvYcCXKu1sFXQ7PpEbC6pqqsimrMgs4gyYdKr/QWux3vRYbiHqgUx9cG2td/cbjysdoNj9ZibB8MflrItTFldJY1uL20enH X-Gm-Message-State: AOJu0Yzrkv7TPGdrCyeVJPL2Plo1WaGP/SndKhESDDunpa9bhZ6beKiA oGM8b67/Ym2VdCji+Xy37oWAyNbVlE5DJsMCJ27ZH9QAhFPO805QNMd+nKrU1aKDMVvlDvgHgtk 19dXjQGZYmeT+w8JsEXvUYipOSxez5WQJ X-Google-Smtp-Source: AGHT+IFyvH9opLDXhVUqWgk6AwPEqnaqYuSF7LgRZbfxSXfGYNXLJdEXg0rswFHIBZB/Yx3O4ydLpIgKm+4w3aLWOTM= X-Received: by 2002:a17:907:f1dc:b0:a7a:9d70:82b9 with SMTP id a640c23a62f3a-a8090c826fcmr2890466b.17.1723072498823; Wed, 07 Aug 2024 16:14:58 -0700 (PDT) In-Reply-To: <871q30t8mh.fsf@protonmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=kien.n.quang@gmail.com; helo=mail-ej1-x62e.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 08 Aug 2024 00:38:02 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322528 Archived-At: > Yes, there is. It makes assumptions about the API implementation that > valid implementations of the Windows API do not satisfy. Wine until last > week is one example; given that the bug wasn't reported in 20 years, we > can assume that no other popular application relies on this particular > detail, so relying on it even in MSVCRT builds is unsafe. > IMHO, the only thing the first patch is missing is a comment reminding > us to remove the old code if and when support for Windows 95/98 is > dropped. Since the UCRT is the replacement of MSVCRT, just putting that behind an ifdef without checking for the function pointer is also fine to me. Eventually, the UCRT, which is receiving all of the security fixes, should be replacing the MSVCRT. On Wed, Aug 7, 2024 at 12:50=E2=80=AFPM Pip Cet wro= te: > > "Eli Zaretskii" writes: > > >> From: Quang Kien Nguyen > >> Date: Tue, 6 Aug 2024 13:52:27 -0700 > >> Cc: emacs-devel@gnu.org, pipcet@protonmail.com > >> @@ -10480,60 +10480,73 @@ init_ntproc (int dumping) > >> /* Initial preparation for subprocess support: replace our standard > >> handles with non-inheritable versions. */ > >> { > >> - HANDLE parent; > >> - HANDLE stdin_save =3D INVALID_HANDLE_VALUE; > >> - HANDLE stdout_save =3D INVALID_HANDLE_VALUE; > >> - HANDLE stderr_save =3D INVALID_HANDLE_VALUE; > >> - > >> - parent =3D GetCurrentProcess (); > >> - > >> - /* ignore errors when duplicating and closing; typically the > >> - handles will be invalid when running as a gui program. */ > >> - DuplicateHandle (parent, > >> - GetStdHandle (STD_INPUT_HANDLE), > >> - parent, > >> - &stdin_save, > >> - 0, > >> - FALSE, > >> - DUPLICATE_SAME_ACCESS); > >> - > >> - DuplicateHandle (parent, > >> - GetStdHandle (STD_OUTPUT_HANDLE), > >> - parent, > >> - &stdout_save, > >> - 0, > >> - FALSE, > >> - DUPLICATE_SAME_ACCESS); > >> - > >> - DuplicateHandle (parent, > >> - GetStdHandle (STD_ERROR_HANDLE), > >> - parent, > >> - &stderr_save, > >> - 0, > >> - FALSE, > >> - DUPLICATE_SAME_ACCESS); > >> - > >> - fclose (stdin); > >> - fclose (stdout); > >> - fclose (stderr); > >> - > >> - if (stdin_save !=3D INVALID_HANDLE_VALUE) > >> - _open_osfhandle ((intptr_t) stdin_save, O_TEXT); > >> + /* For UCRT, the _fdopen will try to find free stream from > >> + _IOB_ENTRIES (=3D 3), thus we can't reopen the standard handle= s > >> + with it. Using SetHandleInformation to make the handle not > >> + inheritable to child process is a better way. */ > > > > This is not what I think we need. First, there's no need to change > > anything in the MSVCRT build, because AFAIK the current code "just > > Yes, there is. It makes assumptions about the API implementation that > valid implementations of the Windows API do not satisfy. Wine until last > week is one example; given that the bug wasn't reported in 20 years, we > can assume that no other popular application relies on this particular > detail, so relying on it even in MSVCRT builds is unsafe. > > IMHO, the only thing the first patch is missing is a comment reminding > us to remove the old code if and when support for Windows 95/98 is > dropped. > > Pip > --=20 Best regards, Kien