From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Sat, 27 Jul 2024 21:50:24 +0300 Message-ID: <86h6ca1xfz.fsf@gnu.org> References: <86le1q54bw.fsf@gnu.org> <86zfq31cvc.fsf@gnu.org> <86ttgb1186.fsf@gnu.org> <86le1m24tx.fsf@gnu.org> <86jzh622p4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11954"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 27 20:51:27 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 1sXmVr-0002y9-Jk for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jul 2024 20:51:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sXmUv-0002wR-Sr; Sat, 27 Jul 2024 14:50:29 -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 1sXmUt-0002vM-Pq for emacs-devel@gnu.org; Sat, 27 Jul 2024 14:50:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sXmUt-0005jH-9X; Sat, 27 Jul 2024 14:50:27 -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=+9FXVz9UFADYpFM0kc9bRpoIA+IOttMrD6UVAJ8/+Cs=; b=RhtQkTL1ve6q JGfu27GmxubA1Pbw4zSPBTkJeY9+uavHRaEXEy890U2L2gy45BFlSImnfPsFdEpestwbhulKjMhgE Oh5tjusqZwkpVSM7Q8QwnuEpoYBSopOlbUBZdTzGnXE/dneikdLx2KAb2u4gmvWo0Uh704IQaH1Oa Aop29u6Nwnu/ryBL1cxf/f2ipunDORHefpVhqJh7hLH8sdKXMu524OZEOuuPR6FiEihQkMqrbMC8i uMVUpnFeoNe+9IoDQI99d/4WzE7imB3VtL2lpq1esEQfj+wsDTjiwrWQ1CyUJkzKtr84uJMmIpE0y V/KX8VqvN9Ydxb2xtvV2/Q==; In-Reply-To: (message from Pip Cet on Sat, 27 Jul 2024 18:27:43 +0000) 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:322139 Archived-At: > Date: Sat, 27 Jul 2024 18:27:43 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org > > On Saturday, July 27th, 2024 at 16:56, Eli Zaretskii wrote: > > then stepping through this code I see that fd is first assigned zero, > > then 1, then 2. As expected, because any decent emulation of Posix > > file descriptors must keep this semantics: file descriptors are reused > > starting from the lowest available slot. > > > > Do you see something different in your build? > > _open_osfhandle returns 0 for the first FD, but _fdopen returns 0x7b281160, while stdin is 0x7b281100. Not on my system. Here _fdopen returns a pointer to the same FILE object as the original std* streams. And it is also expected, since the source code of MSVCRT explicitly shows that _fdopen calls a routine that looks up a vacant stream slot, and that routine examines the _iob[] array in the ascending order of indices, from zero to max, until it finds an unused slot. > I believe that _fdopen (0, "r") returns stdin if it has previously been closed is an implementation detail of Windows that Emacs relies on, and that wine fails to properly emulate. IMHO, this is a wine bug, but Emacs also shouldn't rely on it unless it's documented as part of the API; I don't know whether it is. I believe this is how every Posix-like allocation of FILE objects should behave. I'm astonished that Wine doesn't work like that, since it's the easiest way. Moreover, the MS documentation says about the standard streams: These pointers are constants, and can't be assigned new values. So you cannot do "stdin = _fdopen (...);" and hope for all the references to stdin in the rest of the program to use the new value of the stream pointer. IOW, what Emacs does is the only way of doing that.