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: Sv: A possible small tiny bug in win32 FULL_DEBUG build and some questions Date: Fri, 3 Jan 2025 16:19:06 +0000 Message-ID: References: <86ed1ljfqc.fsf@gnu.org> <86zfk8guvr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_AS8PR02MB101078B4311129B4A820F592796152AS8PR02MB10107eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 03 17:21:13 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 1tTkQC-0004cu-Pb for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jan 2025 17:21:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTkPF-00068w-Lv; Fri, 03 Jan 2025 11:20:13 -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 1tTkOG-0005dk-VH for emacs-devel@gnu.org; Fri, 03 Jan 2025 11:19:12 -0500 Original-Received: from mail-westeuropeazolkn190110001.outbound.protection.outlook.com ([2a01:111:f403:d201::1] helo=AS8PR04CU009.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 1tTkOF-0001a4-3D; Fri, 03 Jan 2025 11:19:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LvIO4J6Y2XDbnICvP2DsDduarm3tk4+NO0oNo94A1UqdkEHHBMU/bGZhXrY5SFfP/yAx942nx+GMasSkmktwNxjcxHjIAWf2nqOYLpKaNJcON/D+vfS7fdQTmje76i8/SnoihpknNmDXB/bmREmGIhDxQdKoe+/d1jGimKKKYmQfvYrPViPZEg7IvOhzFWhIHJzXbHjCa4Nj+B10QL1FtXXLfQ5vbJEpANaug40e9XjGfIgUCzqnv8xX46c5xFIxWXQZcPlxoC+mhRIv7yreQBwxefM1XwhZlvWtuAyaGc4f5nZFXaBbiDlJN0qas57J9ggU4HIdirxvb+bYlgan5Q== 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=uQNmox9+KBjqeUmdUosxiHbF10rutqEFJ6qyzoMfiiM=; b=MSifaf4eV9UczquaZuz9D4DnXAHVprfh0Yez0LsmvKUI0L8NXY29ZsUUtDSOEtzPwHNNgTA/QWokAM5sL8ePce/5k3KrzFW5xx9ZAu4gAsXRb0BZnPULNRM2Dh1Skx0T+irBSufNzAisyWiYJLQHu8YP9kft1rA94rUkjhyZsZK8ZKdUpHwsPKDWE/iIhSSIw7XG1XGNoa7SdkQDA56n7yUlKqBKLIZDWYR5iljRfHdMxq/a6ejomS9JnwOIIX9/5I+plqbLwv/Mox52rEsKo7Kj60clOxR+I/gQNQbr6SA4Zzops6uESVjUfVeKd/WRW1eGcSb3sC3r6YcbDT8j4A== 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=uQNmox9+KBjqeUmdUosxiHbF10rutqEFJ6qyzoMfiiM=; b=dMzWGuy1+hj9V0a3wKtrZwJz+ruaa1C2d2ka2J9CIbd2HAETSixO9E5X0/xlRkSot3sujNiQNF78aOgYZIWQ7FuSjC8djMQZ8I5mlchJzQop1UcSktQDjnN6fXwW+aAjyL1VcdLpMjtzrjhuyJc04mlLRigqfP7gp5AnEBxpJD2soVxj/xNLAzCRnpLmGhdArAcoGv2S30wMrdvWiF2+Tsoe56bDcvpb8U1DMFwGUfVMWHkejMatAXCehdwUxtZBUaMc62J5pMtXfdoH86Ub7QSHHijHSC7kgreUaV1KwxiboGb2ntdM1AtPldYR0J4We5mqSzNoSoFno1JiG7gvfQ== Original-Received: from AS8PR02MB10107.eurprd02.prod.outlook.com (2603:10a6:20b:633::7) by DU0PR02MB8691.eurprd02.prod.outlook.com (2603:10a6:10:3ee::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.12; Fri, 3 Jan 2025 16:19:06 +0000 Original-Received: from AS8PR02MB10107.eurprd02.prod.outlook.com ([fe80::80fe:77a2:35b:dfc]) by AS8PR02MB10107.eurprd02.prod.outlook.com ([fe80::80fe:77a2:35b:dfc%7]) with mapi id 15.20.8314.013; Fri, 3 Jan 2025 16:19:06 +0000 Thread-Topic: A possible small tiny bug in win32 FULL_DEBUG build and some questions Thread-Index: AQHbXS8vmEjdcmLDBEyktl+mLWFPpbMDupjmgAB0fEeAAIqwn4AAgcwy In-Reply-To: <86zfk8guvr.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR02MB10107:EE_|DU0PR02MB8691:EE_ x-ms-office365-filtering-correlation-id: 13e5a01e-07c6-42d3-c30a-08dd2c12589d x-microsoft-antispam: BCL:0; ARA:14566002|8060799006|15080799006|19110799003|461199028|15030799003|8062599003|7092599003|440099028|3412199025|102099032; x-microsoft-antispam-message-info: =?iso-8859-1?Q?ECxf1R9jPDhp9oCjxg3vFwwFM5onFFfraCwaID7kAc01agxJN9MYkYbrKp?= =?iso-8859-1?Q?e18KtAbtwklc8hwIMZR00pk836c3y+g9UuauaFTZ6jh6jJ8jnNSX2SDWpe?= =?iso-8859-1?Q?BFG+pszyINSi34BZStoAKMhD67obo+4u/Y1fJ4iU2n8tsewLdpYQf+WjXG?= =?iso-8859-1?Q?DbNf7Dm/egGDnzHBpiUolQoOX7ZAx66iw/3c6STWXH3sYvBe4RauP98Gbr?= =?iso-8859-1?Q?4KYh0OyHBWmVcl/On7ualT0d3eZ/gj04+ezvAHnXKtu2uCV8W/YrGwgJJF?= =?iso-8859-1?Q?3Eucn2j/icYdVnCO6pOgO4pFBlM6mwFkxaZfaJ/wlumsiMfE3Y1o8vCQLL?= =?iso-8859-1?Q?0VS+gMCqsgGwBAtFZ/8QaEhRiaF+Mu+S6jivbX5UVoDxqyM5qu5JVa0LBl?= =?iso-8859-1?Q?B75tWCy9hswls+5nV4TFmi/5yomvukDZa9/D1yY7fXlj3ZAPybhq/m5kpI?= =?iso-8859-1?Q?JumOX9irUm7Mfl+6O0UNr7EoyCFNBy3Dw2UrzZZVYrpkkFudhA4mkxT3eY?= =?iso-8859-1?Q?ltsPp4wsuQSp3puUWTVMqPWuCtE+ZSsll61UFBQll5B7TXgpm4s7/PoECg?= =?iso-8859-1?Q?sx7Iw57c8Z+IL8E2HX4L2ZAId4hs5YUu7iVPRxJUqC27FTxEoMJca6m71D?= =?iso-8859-1?Q?kBX x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?jesPWQvsAfYZHbwlqMR+kyCnLfIda04HCDDhcZhDKD/zNFM9qlplcYAXkR?= =?iso-8859-1?Q?FYYYSmUvwnkaAYhKYabTbijIlzsg+q0xbxf8f4LW3+y3CksC/L7WxQuJBM?= =?iso-8859-1?Q?RwepoIKWIfTDUQeBvaRsfKE5kAj+glzHJoQqcSqy3CY9NpDUt2JszOycqZ?= =?iso-8859-1?Q?z3OgWvVA/ghvNldKdt9n/G+juTM6y+LIWguWMStmIrsCwvCXKKmgho7DOh?= =?iso-8859-1?Q?CcAX0saQ1+09FkvbSxXsw3301GMIg1asNQz0I6T9NnbhBMJE8wT7l2zAXa?= =?iso-8859-1?Q?THVHBo1nk0c/yoQ31j2tbFbz8tzV/rPeS4pg8OKTIjMJ9gNkQLUiRTc0/H?= =?iso-8859-1?Q?FaMAAJfGtDcXXEX1nijicTY5V7eKqTCoX1bk9dHAyL7+XnqGI5xjK+2Ivx?= =?iso-8859-1?Q?zutFmqMFQeGSAwmRsySncjddt778nrb5RAZ8q/R9ESyGQ/YFsRceVsAQUS?= =?iso-8859-1?Q?gyfWkVLBr9DqELvp3EKX5AcRZDKO2yjTf83coe8yv3j0eVyXn5rZaZ7uGL?= =?iso-8859-1?Q?gUqF25TmCmH3p20JYavyI5DnhC21NmkyektGi/FEZUKEFLx4+pJlaDx4IQ?= =?iso-8859-1?Q?QWhDfNkWIu1sm+qynLlLfr5Wkcm3J6uPsfgMuXzi3Kwh/D/qiBxjX9JoJT?= =?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: AS8PR02MB10107.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 13e5a01e-07c6-42d3-c30a-08dd2c12589d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2025 16:19:06.3776 (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: DU0PR02MB8691 Received-SPF: pass client-ip=2a01:111:f403:d201::1; envelope-from=arthur.miller@live.com; helo=AS8PR04CU009.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 03 Jan 2025 11:20:12 -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:327632 Archived-At: --_000_AS8PR02MB101078B4311129B4A820F592796152AS8PR02MB10107eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > From: arthur miller > > CC: "emacs-devel@gnu.org" > > Date: Fri, 3 Jan 2025 00:24:58 +0000 > > > > (let ((cp (w32-get-console-codepage)) > > (cpo (w32-get-console-output-codepage))) > > (dotimes (i 100000) > > (w32-set-console-codepage i) > > (w32-set-console-output-codepage i) > > (w32-set-console-codepage (- i 10000)) > > (w32-set-console-output-codepage (- i 10000))) > > (w32-set-console-codepage cp) > > (w32-set-console-output-codepage cpo)) > > > > Anyway, in the world of utf8 I guess nobody is using that code anyway, > > so it does not really matter. Was just a little curiosa while I was > > looking through the code for the reference. > > The codepages are still very much used in Emacs on Windows. The > Windows UTF-8 support is rudimentary and marked "experimental" by MS. > So we still need to consider the codepages when referencing external > stuff. Ok; thnks. I thought Emacs was doing its own coding/decoding, but I am not yet familiar with that stuff. I guess I'll have more questions about that stuff. > > >> 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 c= alled 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 glob= al 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. > > > > I am assuming that this function can't be used very often. If the user > > calls it for some reason (debugging, curiosity, checking if a codepage > > is loaded?), the list will be constructed, but probably not used in a > > single usage. But the space allocated for it will be allocated until > > Emacs exists. If space is used but not needed than in a sense, it is a > > memory leak. > > That's not a memory leak in my book, no. A value that is computed > once and left to be used for the entire session is not a leak. Mnjah; of course, I don't know why this particular function was implemented, but my guess is debugging or just a simple check if a page is loaded or something? I would guess the usage is rather temporary in a single place or just occasionally. If some user could have a reason to save it for the entire duration of an Emacs session they could save it in a lisp variable themselves. As now, since there is a global reference protected from GC, in the most probable case, the list will be left alive for the life of the session, even if they don't use it. Anyway, thanks for the explanations. --_000_AS8PR02MB101078B4311129B4A820F592796152AS8PR02MB10107eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> > From: arthur miller <arthur.miller@live.com>
> > CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> > Date: Fri, 3 Jan 2025 00:24:58 +0000
> >
> > (let ((cp (w32-get-console-codepage))
> >       (cpo (w32-get-console-output-codepage)))
> >   (dotimes (i 100000)
> >     (w32-set-console-codepage i)
> >     (w32-set-console-output-codepage i)
> >     (w32-set-console-codepage (- i 10000))
> >     (w32-set-console-output-codepage (- i 10000)))
> >   (w32-set-console-codepage cp)
> >   (w32-set-console-output-codepage cpo))
> >
> > Anyway, in the world of utf8 I guess nobody is using that code an= yway,
> > so it does not really matter. Was just a little curiosa while I w= as
> > looking through the code for the reference.
>
> The codepages are still very much used in Emacs on Windows.  The<= /div>
> Windows UTF-8 support is rudimentary and marked "experimental&quo= t; by MS.
> So we still need to consider the codepages when referencing external
> stuff.

Ok; thnks. I thought Emacs was doing its own coding/decoding, but I am
not yet familiar with that stuff. I guess I'll have more questions about
that stuff.

> > >> 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 event= ually 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 t= hat the global list can
> > >> be freed so not to leak that list in the case the user d= oes 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.
> >
> > I am assuming that this function can't be used very often. If the= user
> > calls it for some reason (debugging, curiosity, checking if a cod= epage
> > is loaded?), the list will be constructed, but probably not used = in a
> > single usage. But the space allocated for it will be allocated un= til
> > Emacs exists. If space is used but not needed than in a sense, it= is a
> > memory leak.
>
> That's not a memory leak in my book, no.  A value that is compute= d
> once and left to be used for the entire session is not a leak.

Mnjah; of course, I don't know why this particular function was
implemented, but my guess is debugging or just a simple check if a page
is loaded or something? I would guess the usage is rather temporary in a
single place or just occasionally. If some user could have a reason to
save it for the entire duration of an Emacs session they could save it
in a lisp variable themselves. As now, since there is a global
reference protected from GC, in the most probable case, the list will be
left alive for the life of the session, even if they don't use it.

Anyway, thanks for the explanations.
--_000_AS8PR02MB101078B4311129B4A820F592796152AS8PR02MB10107eu_--