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: A possible small tiny bug in win32 FULL_DEBUG build and some questions Date: Thu, 02 Jan 2025 19:19:23 +0200 Message-ID: <86ed1ljfqc.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11645"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: arthur miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 02 18:20:19 2025 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 1tTOrr-0002sq-OL for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jan 2025 18:20:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTOr7-0002Io-3z; Thu, 02 Jan 2025 12:19:33 -0500 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 1tTOr1-0002HO-8Q for emacs-devel@gnu.org; Thu, 02 Jan 2025 12:19:28 -0500 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 1tTOr0-0005Tx-TQ; Thu, 02 Jan 2025 12:19:26 -0500 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=aJhd9p+6ASKdHEYeWfDahELf8FCzsxjxHu1keIGS99k=; b=OesPUYKqBjSL e9ihXxkIJFWziojryCd3IwtFjGWcdHrG8aLJH8sJ64TnPZcN/edYa6Mu4v0bqGpL75as3XKpu2IeC 9UZ7kL8xpyg7onJcSz6+stJpQcDkABZqgzz5zcL6ty2oogMH2bjcQlKPyQBOHM2EQy8D1OKRi8EzL XjPrd57XpTPkYrYKLKpzkj9QCM1h6UmUtTUpaMDOLhKsTHhKVrYh1IbXAE43Zc+e/mxMXmjmeR0sH oRy9iczh3xcKtq/VYQGVTVmPegoyNvUThXoTTot/7ViJ0wzogtQ3h8yXo1J8/pFYFxioJeqMOr9Nu GPAD0LY9Kk1VD5M+yRU8QQ==; In-Reply-To: (message from arthur miller on Thu, 2 Jan 2025 15:59:32 +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:327575 Archived-At: > From: arthur miller > Date: Thu, 2 Jan 2025 15:59:32 +0000 > > Tiny bug: line 2447 in w32proc.c should probably read: cp->child_procs; not > cp-child_procs. Why do you think so? child_procs is not a member of 'struct _child_process', as you can see in w32.h, so cp->child_procs will not compile. 'cp-child_procs' yields the ordinal number of the child process in the child_procs[] array, which is what that debugging printf wants to produce. > Possible tiny opt/simplification: SetConsoleCP & SetConsoleOutputCP > already do check for validity themselves (as far as I have tested with invalid > codepages), so it is possible to simplify those two: > > DEFUN ("w32-set-console-codepage", Fw32_set_console_codepage, > Sw32_set_console_codepage, 1, 1, 0, > doc: /* Make Windows codepage CP be the codepage for Emacs tty keyboard input. > This codepage setting affects keyboard input in tty mode. > If successful, the new CP is returned, otherwise nil. */) > (Lisp_Object cp) > { > CHECK_FIXNUM (cp); > > if (SetConsoleCP (XFIXNUM (cp)) != 0) > return make_fixnum (GetConsoleCP ()); > return Qnil; > } > > DEFUN ("w32-set-console-output-codepage", Fw32_set_console_output_codepage, > Sw32_set_console_output_codepage, 1, 1, 0, > doc: /* Make Windows codepage CP be the codepage for Emacs console output. > This codepage setting affects display in tty mode. > If successful, the new CP is returned, otherwise nil. */) > (Lisp_Object cp) > { > CHECK_FIXNUM (cp); > > if (SetConsoleOutputCP (XFIXNUM (cp)) != 0) > return make_fixnum (GetConsoleOutputCP ()); > return Qnil; > } > > Msdn (or whatever they call it now) docs says it returns 0 if it does not > succeed. I have tested with few invalid numbers for CPs and those functions seem > to work fine for me. I am not expert on win32, perhaps there is something I miss > there? Nothing important, but if you want I can give you a patch. We generally prefer not to call Win32 APIs with invalid parameters, if that could be avoided, because doing that could cause an abort. So I don't think this optimization is worth the risk. > Does GC-protected variables, those delcared as "staticpro", works the way I > think they work: GC never collects them? Yes. > If I enum all codepages with w32-get-valid-codepages, than the list will forever > stay alive? Yes. But its value could change if you call the function again, in which case the old value will be GC'ed at some point. > Even if the result from the function is never assigned to a variable > int the user code? Yes, even so. > I don't see any usage of this function, neither in C code nor > in Lisp (I grepped through); so I guess it is just eventually only called from > the external packages or just interactively by the user. Is it worth to copy > the returned list into a local list and return that so that the global list can > be freed so not to leak that list in the case the user does not want to save > that list anyway? I don't understand where did you see a leak, and what kind of a leak is that, please elaborate. > Another question: can list of valid codepages on the system change during the > runtime? I suspect yes, if the user installs additional codepages. But I don't really know. > Would it be OK to check if the list is alreay built, and just return > it, instead of setting the list to nil on each run and re-computing it? I guess > it is not something that changes often? I don't know really how it works on the > system level, so just a question. I don't see why risk the possibility that the list changes behind our back. What important advantages will we gain? > Also, is it important that this list is in some particular order? Why reversing > it before returning it? I guess we want to return the list in the order the OS enumerates them, not in the reverse order. Again, why is this important? I don't think this function is likely to be called inside tight loops, is it?