From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: A possible small tiny bug in win32 FULL_DEBUG build and some questions Date: Thu, 2 Jan 2025 15:59:32 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1PR02MB10098B3AF2D31EC2BA800DD7696142VI1PR02MB10098eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28727"; mail-complaints-to="usenet@ciao.gmane.io" To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 02 17:44:10 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 1tTOIr-0007Lr-FT for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jan 2025 17:44:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTOI7-0008CV-VQ; Thu, 02 Jan 2025 11:43:24 -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 1tTNgd-0000wp-Sw for emacs-devel@gnu.org; Thu, 02 Jan 2025 11:04:40 -0500 Original-Received: from mail-am6eur05olkn2057.outbound.protection.outlook.com ([40.92.91.57] helo=EUR05-AM6-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 1tTNgb-0007Qi-GS for emacs-devel@gnu.org; Thu, 02 Jan 2025 11:04:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=w2rvAzuIF59/GIGEP6uphJM1dcJRppHBw+bNATYiugpKJLLOsFBrjV4WcQH2//+GUVxphbw2VKaV6qAJAnSHHta2ygnDey9dUZWJoA14N91mayiLSvCrUALNo5tFFc1+Oss7crgP/brYEH5XursAh1Hwd0pMql9rpXvmYntUTIFzb/QsvBVhHjoMAAnPc63aW5va3aSP883Sxp8sWtPnK7VJfSvrwG6H4TKaakQql9a2x3uBGNn7ZMG2z1aPu4V2cWrh3E1AkRaeEOZ016qXOpHJ5hyqlTdoLaES1ThubuQ+X+7oW36eRJwItNG5HxZWhiORmIaUqWl8H8JLBVbcIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=JNVk8emNGF9OALy6978hfNHTFOgwp8dB5cXrRLOOhzc=; b=jd1FY0dW6c/9ObT4uzLcfgYP3j35alp73R9Ol4fFoImd6nmU/VCx1rE8m5VK9CgtIXmKGJZzLt1TCQnNYHIbHW9gbeg5rL6gfYKbrOMcs1YX5+sWFvF9xAE6lt17MJ+hEgUuahNmTRO6BAKpO4anuMe5AJpQDreS3M5xRIU1Hp4XbLLV62nF9ebq275dt+vqKvqf6FwAU+NwKjnlZsynymKQW4/4iEzjLtaLnQwuimja+8MqV3pUhF0pHqkWLr/yBdrq67e9+yz5cnqCGzFofd6wqssCgWkR7sDWhM1Yxnu/pbdnyyQfw8QNHCkJjQBwixJPmKEuklfY5LXv+fYHbg== 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=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JNVk8emNGF9OALy6978hfNHTFOgwp8dB5cXrRLOOhzc=; b=YMuoyFPvdYAn8+aVosdLbhf6tHvZjpuX07ys+zfJ9yPBTkqfoZObvK5WFrH0qJncB/9nxTozYo2PmggrHiAS7iVqLt/87U0Y8ENOFtrgt+h79tYP4cR3RWlXGu7oTMfAJkennDR3mUsA5MTDoKxwDI7Bey3dChETZNE0CohKmaQnQJ1p2c1rgSYjoF2e8uU75m6cjedpyuRmQZqKGlZxNHerJBLXpA3DUIUD9cy1owYWhDWEiQQPkyL8zqdnnI1+HQh7bvT+GjBxFXIgOBSFARgJHFVcOcgS5j+PbOrjZF1yI7hS9AsTfrXYRxSv3Kn42YHtKoVMxVnS05Gc2mj1bA== Original-Received: from VI1PR02MB10098.eurprd02.prod.outlook.com (2603:10a6:800:1c4::22) by PA4PR02MB8214.eurprd02.prod.outlook.com (2603:10a6:102:26b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.13; Thu, 2 Jan 2025 15:59:32 +0000 Original-Received: from VI1PR02MB10098.eurprd02.prod.outlook.com ([fe80::27cb:35b9:33a7:7d12]) by VI1PR02MB10098.eurprd02.prod.outlook.com ([fe80::27cb:35b9:33a7:7d12%6]) with mapi id 15.20.8293.000; Thu, 2 Jan 2025 15:59:32 +0000 Thread-Topic: A possible small tiny bug in win32 FULL_DEBUG build and some questions Thread-Index: AQHbXS8vmEjdcmLDBEyktl+mLWFPpQ== Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI1PR02MB10098:EE_|PA4PR02MB8214:EE_ x-ms-office365-filtering-correlation-id: 492597f3-a7b5-4be9-92e5-08dd2b46725f x-microsoft-antispam: BCL:0; ARA:14566002|8062599003|19110799003|8060799006|15080799006|461199028|15030799003|7092599003|102099032|3412199025|440099028; x-microsoft-antispam-message-info: =?iso-8859-1?Q?cmIwjg+c/Y2BW4dUundJjM9U5da2PgUUyFYM/UqJqAbRE7NVeG+zR7Z88S?= =?iso-8859-1?Q?1dkBB9bXKt9adp3KcPOvZ9xZt6tSpBThVThXnLzS3yKZ0rngQA11mYCtW8?= =?iso-8859-1?Q?FEIn0QQ6JGfdjeeObPhkmJG8ieaW23DP5BQy8G8mEXEsoiLFJhXW3H657e?= =?iso-8859-1?Q?oTAJzbmFB9qP1IYEeFeIss+nKh2Cpj/39r/lYU18zR5Y9HRRE/vok8+lrr?= =?iso-8859-1?Q?ZHHvZpS/nbxmsW4hWHugZJQcdECJdzSfV1K1sPMtYl0qYwkHKro5xGrSPv?= =?iso-8859-1?Q?qN7Tnig0V8uZ7KMgGar8vInt/53fw72cYHl5KPUhhY2TnlCNANGkYVi/Tb?= =?iso-8859-1?Q?32Nc38IHsa/wsgJR2z5vBLX8EwshTyT28I6NRcnHKHUtcXGHWJFAOfjffT?= =?iso-8859-1?Q?s1UQa+hVi0IPSDVAVpil/QAmWmqAmwfzBchnwnWAgRt1pAf9rkyHFLCaP6?= =?iso-8859-1?Q?Z4iZX15yvKuxEjwhhovde4yEYoRKvD7Ok2Yu+4QgKYU88TmBjElSOIdHQs?= =?iso-8859-1?Q?GNDTo+MH0LtdAhgBS+gj6EA0a2Pvd3fVH5YOkMemmSvEArd1MGFrQyIWES?= =?iso-8859-1?Q?QGMdiGNYmBJf0zpxHyJ3AFqYM5Bfoz6Djo8eRRziv6ljBhDzsS0N+cMV/x?= =?iso-8859-1?Q?HQ4 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HkqQrs9k8mVosm8s1GzP9pt+la0m7s5LnmvgqqtJQEWzlRW0XaQs3ZwqPX?= =?iso-8859-1?Q?ehNFUnUGLwQ78sIbWvJBv27c22iu60RjVjoRufbjZE2xQmx4vj6PR4YYCq?= =?iso-8859-1?Q?amUy7zol3DeX6sq/PLSBeZhawnkrGHc2oEb+y8AuaZ2La4yhm36DjX8u5R?= =?iso-8859-1?Q?YLrg9oi7jSzh6Uj7jXo3lwEjHlBldCFXQLhxjxVl13BBRxUD52KFmUdXoV?= =?iso-8859-1?Q?rmon22ivMb0VHy1f43L1PqZ0w26lSw7g9tGU0X1HXkzFwtlAaKMmHejzFn?= =?iso-8859-1?Q?WJMO8To1ich1KBqbrokT327YkQfuuuluyLaEOZKyAGQVxqOvxklBRd7zLZ?= =?iso-8859-1?Q?ZkOjjylfRQAUd30qBKmzrE9Typ/09oWIDvZdcJ0M9UOdXxfft+Bq2zZLP7?= =?iso-8859-1?Q?+Ozif7Xe8qlG0hFwnpldNOXrSCKaHD7dsL+ix/CsuCDCD2RVuHu0dDodoe?= =?iso-8859-1?Q?jQszuYpkwthTbdIsu9WKnJaq+MigkpS5V3PzcjjF2pxNE3bmbKuFFOjQDT?= =?iso-8859-1?Q?XMLAm4PgBb7r1bTdJaE9VMgjf9b1M1HEsIRHlWi6MUiUOB2OzXvKd5apo4?= =?iso-8859-1?Q?wBPLuPEZaaAqzZ3iYLAoTh0seiC+JMHY53hm+2fbBiw3XyeSDgs+vyecKR?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR02MB10098.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 492597f3-a7b5-4be9-92e5-08dd2b46725f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2025 15:59:32.2751 (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: PA4PR02MB8214 Received-SPF: pass client-ip=40.92.91.57; envelope-from=arthur.miller@live.com; helo=EUR05-AM6-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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 02 Jan 2025 11:43:21 -0500 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:327572 Archived-At: --_000_VI1PR02MB10098B3AF2D31EC2BA800DD7696142VI1PR02MB10098eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tiny bug: line 2447 in w32proc.c should probably read: cp->child_procs; not cp-child_procs. Possible tiny opt/simplification: SetConsoleCP & SetConsoleOutputCP already do check for validity themselves (as far as I have tested with inva= lid 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 keybo= ard 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)) !=3D 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 o= utput. 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)) !=3D 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. Some questions: Does GC-protected variables, those delcared as "staticpro", works the way I think they work: GC never collects them? If I enum all codepages with w32-get-valid-codepages, than the list will fo= rever stay alive? Even if the result from the function is never assigned to a var= iable int the user code? I don't see any usage of this function, neither in C cod= e nor in Lisp (I grepped through); so I guess it is just eventually only called f= rom the external packages or just interactively by the user. Is it worth to cop= y 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 sav= e that list anyway? Another question: can list of valid codepages on the system change during t= he runtime? Would it be OK to check if the list is alreay built, and just retu= rn it, instead of setting the list to nil on each run and re-computing it? I g= uess it is not something that changes often? I don't know really how it works on= the system level, so just a question. Also, is it important that this list is in some particular order? Why rever= sing it before returning it? --_000_VI1PR02MB10098B3AF2D31EC2BA800DD7696142VI1PR02MB10098eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tiny bug: line 2447 in w32proc.c should probably read: cp->child_procs; = not
cp-child_procs.

Possible tiny opt/simplification: SetConsoleCP & SetConsoleOutputCP
already do check for validity themselves (as far as I have tested with inva= lid
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)) !=3D 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)) !=3D 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.

Some questions:

Does GC-protected variables, those delcared as "staticpro", works= the way I
think they work: GC never collects them?

If I enum all codepages with w32-get-valid-codepages, than the list will fo= rever
stay alive? Even if the result from the function is never assigned to a var= iable
int the user code? I don't see any usage of this function, neither in C cod= e nor
in Lisp (I grepped through); so I guess it is just eventually only called f= rom
the external packages or just interactively by the user. Is it worth to cop= y
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 sav= e
that list anyway?

Another question: can list of valid codepages on the system change during t= he
runtime? Would it be OK to check if the list is alreay built, and just retu= rn
it, instead of setting the list to nil on each run and re-computing it? I g= uess
it is not something that changes often? I don't know really how it works on= the
system level, so just a question.

Also, is it important that this list is in some particular order? Why rever= sing
it before returning it?
--_000_VI1PR02MB10098B3AF2D31EC2BA800DD7696142VI1PR02MB10098eu_--