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 00:24:58 +0000 Message-ID: References: <86ed1ljfqc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_AS8PR02MB101075C8F0899BBC64608AD7396152AS8PR02MB10107eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22702"; 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 07:33:38 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 1tTbFZ-0005jA-S8 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jan 2025 07:33:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTbEm-0007XQ-Ir; Fri, 03 Jan 2025 01:32:48 -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 1tTVUv-0005Qt-7Q for emacs-devel@gnu.org; Thu, 02 Jan 2025 19:25:05 -0500 Original-Received: from mail-am6eur05olkn2067.outbound.protection.outlook.com ([40.92.91.67] 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 1tTVUs-0004L2-6e; Thu, 02 Jan 2025 19:25:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BSZ4xapyjt9nnX+6yfZk23sxbrAW9dpt7gb0tq0WHI8/iuoaoo3Uy2QmqDqau0qUFi9b1sPcfug2h2C6HhgoflhPE+8UOpJ3r7YA1eC5dmPF4uT5kM4IQQXva0v2d9UUNfpLFFMZfQE/i0RdY/7M0gefj8y6M8apHyURyO4uGH/2vEZK6YmACcVEqyGAcPh2YdFbB2LP+migvP9ryMPKCk2Vj054BvmtDA5d3mLAkJWlsSnXbQCcgwXvB4jVik7f+uj24n9DCDBGpj5V2bWVcmNeYAJoQrL5B9lMzFIaeH+DVgCGB1r+fAucKpCgYof39btEYjs/FeNdxu9z5rzSNg== 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=PPetrr3WRd+LYUHy3Ukm7R5TRE5nbEQK4zd2ZsD+a+k=; b=hBp6e5cCuxBixIWPOajbnU6IqYsAX3P58npu7t0P8GPcRRfIE1qFxuTCq7xHMvWBYT3xtBMzPpOGWX/snE3DZmeAJSvlh6kaBoR+1l1kdPde/ss+eZC7pp4+p3uYC/rRzouKZS4ICqtqs56kXkkdBomZRqViG1xowtt/GY+Fh9asLVgD5nSgBS9Pbs4SG3jsXYA+CNFnqdlLYDLOv9ChrQS1NmuGiTQaDq0pASMvKRKlO27ejVoRmj2lz7KMqtVcxe66of+c9s+gcsHrUDmwtgqoVBY6o/ZgR0gusdmC3rIepAUCHwPWPezntCly5yVXQyqgm7B3txLQ/G5SPu/Dyg== 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=PPetrr3WRd+LYUHy3Ukm7R5TRE5nbEQK4zd2ZsD+a+k=; b=eYkaiak/x0hj8r0RwZ1CYDtZUd4g4fzxIQl/QwQpXJLIYXXPBhRQSztcHCE/LhoivpVYccX4MXdJWSoZHKU7BwLMYTfy7FXl2uJCf6bUhrRVxbIrXtyzQS/5mNgZJPj+FYPTlqwNelSibvkmG2ai4aAhpEfZOLUorYF+dPmPsc7UNFvkHkSexX0wUhB7jbP8zBKAtbVVZvsnqoGtifvX59wdf1SkHkKx4v6/W623gRxIaB5nd/IQtonatU445JKHDO9LEtHZiLJa3LdFds7DkxuYgiWoFGFZyMZFoZHAnTPLcKl+FelQ+qtgOOtL4LOFj0DDxheJ0eC/exJcVKYFDg== Original-Received: from AS8PR02MB10107.eurprd02.prod.outlook.com (2603:10a6:20b:633::7) by AS8PR02MB8592.eurprd02.prod.outlook.com (2603:10a6:20b:54d::15) 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 00:24:58 +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 00:24:58 +0000 Thread-Topic: A possible small tiny bug in win32 FULL_DEBUG build and some questions Thread-Index: AQHbXS8vmEjdcmLDBEyktl+mLWFPpbMDupjmgAB0fEc= In-Reply-To: <86ed1ljfqc.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_|AS8PR02MB8592:EE_ x-ms-office365-filtering-correlation-id: cbfabc47-58bf-4704-4602-08dd2b8d0e37 x-microsoft-antispam: BCL:0; ARA:14566002|19110799003|15030799003|461199028|15080799006|8062599003|7092599003|8060799006|102099032|440099028|3412199025; x-microsoft-antispam-message-info: =?iso-8859-1?Q?OcFbCfKFogxXgeRzhrGHhzuFdnD5ogs01LBEBGUgEV0+eO/sSJAY1TaaYM?= =?iso-8859-1?Q?9OemVwhjiwnZRClsN3w4YVszTBOX0LpRQB3s7ImpVLdKCkXmieVhlDjvBi?= =?iso-8859-1?Q?mWGPm63k+JIsfdjoOuKpqsogl5bcOBvFYshdWmfnnTP0j3Qp3bW3QWO/KE?= =?iso-8859-1?Q?MChM5tEY0m3CsyPcaHRODZE9RU8myJ60ZdccMS3ddb0eQtcbmEhJg6Vg5h?= =?iso-8859-1?Q?J/qA2VwchRyWGk0T+Uro3yqVUiTgivyQ1voNDKvDMCh+nkVTVl+4JBJ+eJ?= =?iso-8859-1?Q?17sE91EkVpefTF+VedikXENlHvX8J7w1R9/wXZiy1iHEqgaNrZ9u0SKk7S?= =?iso-8859-1?Q?eO7JLnjPKoc0IANLTK/auw7l9qDMsAv8s7hayuwGsqQnL52Dkl8kRzuFN0?= =?iso-8859-1?Q?acJwoHsp9q1LP6dxSL0o5cHFs9TYjS56S1z4Zb3VH2Fea3cVMVZYZW0Gx5?= =?iso-8859-1?Q?Fr5Z43hgz8W4GB6860yWe3fCf0DvioujRQyY5b5Spz/SmBFUAg99Lpvie1?= =?iso-8859-1?Q?xStV3tDGuraY/PoWaAtnz3IV/VQYRtVgLDmDoMBJV19ZWUyC4SIKtC2FRY?= =?iso-8859-1?Q?9NcpZhLgG1yK0/Is0OFSotapN3zeNVJ2oU28Mr3mtornCctedCpQwmxQzW?= =?iso-8859-1?Q?cMW x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?kayMklV5c0Tgk3Qi8Y8P27i50Ewf5dmWx0Ia8gthJl8iJ5o8YD5e6BVrJT?= =?iso-8859-1?Q?kvgD6BplAcJKU2tnZaz54+O+tL8nuEuHTXgjTkUktj9W6hmlZRHfeWTmJj?= =?iso-8859-1?Q?NdUvJVwFOCjjtb6QVGinDV9uLn+CvQNnE5j3QHI60Qs4q8R3GVmNOB6IPi?= =?iso-8859-1?Q?MPd8XoS/W2X2Xj6OsmeV96sRjCwjj/URnD09mw5Ol3b+bs7BOZHYdWBH01?= =?iso-8859-1?Q?GmsfGph3B4m/fR1Df0XCJVY47MZv1QHFBUdnabf9virdPjz3cV+FYyHjSk?= =?iso-8859-1?Q?gLVKWG7lLGRmPL29WEUYi2L6JkGyJdtkiQNytvey0eSDIqWDFF6oNXHd6+?= =?iso-8859-1?Q?IChN5Z27hvoc+VSwizI4mWh3Mr4kVOtcso/9XRFCzlz4mnQsodJ53i/7gz?= =?iso-8859-1?Q?eCAdnrOIQWqT8jm+UJqxMqzTR/wuMqCOQy51kWXNzH76GBXsmgpJblCJol?= =?iso-8859-1?Q?/JriuR2T5ATlBiSMOrvvcicda//bZhK8+bjqcmG8h8MH1roDR0F0Jeb0fP?= =?iso-8859-1?Q?8MrzisBmJodLCumUYKcGdtUL+pC8arpAiqHpFj5UtGBbAr/KdCUIi87Ptw?= =?iso-8859-1?Q?7NUTPidChhAW+/eaTpeAw8MrOvcoFT7aM8Vxk4tgi9UppkCVlteUx9FFMh?= =?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: cbfabc47-58bf-4704-4602-08dd2b8d0e37 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2025 00:24:58.4989 (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: AS8PR02MB8592 Received-SPF: pass client-ip=40.92.91.67; 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: Fri, 03 Jan 2025 01:32:46 -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:327609 Archived-At: --_000_AS8PR02MB101075C8F0899BBC64608AD7396152AS8PR02MB10107eu_ 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. > >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. :-) Ah that was a minus :-). Sorry my bad; I should have looked into the structure. I was looking through the file and the eye just catched the 'kebak-case' name. I just assumed it was a possible typo, since I saw it surroneded by those two idefs. Sorry for the alarm there. >> Possible tiny opt/simplification: SetConsoleCP & SetConsoleOutputCP >> already do check for validity themselves (as far as I have tested with i= nvalid >> 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 ke= yboard 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_codepa= ge, >> Sw32_set_console_output_codepage, 1, 1, 0, >> doc: /* Make Windows codepage CP be the codepage for Emacs consol= e 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 no= t >> succeed. I have tested with few invalid numbers for CPs and those functi= ons seem >> to work fine for me. I am not expert on win32, perhaps there is somethin= g 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. I understand; that is the safe practice. In those particular two cases, they do give guarantee to return zero if they fail; according to their docs. I guess they are actually calling the same function themselves. I did this little test with the patched functions just for the curiosity and it didn't abort anything: (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. >> Does GC-protected variables, those delcared as "staticpro", works the wa= y 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. Thanks. >> 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 calle= d 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 l= ist 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. >> Another question: can list of valid codepages on the system change durin= g the >> runtime? > >I suspect yes, if the user installs additional codepages. But I don't >really know. Sounds reasonable; in that case the list should be recomputed every time. >> 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? Yes, per above, I was just unsure if that is something constant in the system, or can chnage during the runtime. >I guess we want to return the list in the order the OS enumerates MS does not state any order of enumaration for this list, and the return value does not seem to be sorted in some order, so any code that would actually consult this list can't rely on any order and should probably use functions like member or find; not elt or nth. >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? Of course not. Actually I don't think myself this function will be called much at all. Codepages are more or less pass=E9 in the world of utf8; so that is probably old cruft that is used on old systems, or is that still needed? --_000_AS8PR02MB101075C8F0899BBC64608AD7396152AS8PR02MB10107eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>> Tiny bug: line 2447 in w32proc.c should probably read: cp->chil= d_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 no= t
>compile.  'cp-child_procs' yields the ordinal number of the child<= /div>
>process in the child_procs[] array, which is what that debugging
>printf wants to produce.

:-) Ah that was a minus :-). Sorry my bad; I should have looked into the
structure. I was looking through the file and the eye just  catched th= e
'kebak-case' name. I just assumed it was a possible typo, since I saw it
surroneded by those two idefs. Sorry for the alarm there.


>> Possible tiny opt/simplification: SetConsoleCP & SetConsoleOut= putCP
>> 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_code= page,
>>        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_conso= le_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 d= oes 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 so= mething I miss
>> there? Nothing important, but if you want I can give you a patch.<= /div>
>
>We generally prefer not to call Win32 APIs with invalid parameters, if<= /div>
>that could be avoided, because doing that could cause an abort.  S= o I
>don't think this optimization is worth the risk.

I understand; that is the safe practice. In those particular two cases,
they do give guarantee to return zero if they fail; according to their
docs. I guess they are actually calling the same function themselves. I
did this little test with the patched functions just for the curiosity
and it didn't abort anything:

(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.

>> Does GC-protected variables, those delcared as "staticpro&quo= t;, works the way I
>> think they work: GC never collects them?
>
>Yes.
>
>> If I enum all codepages with w32-get-valid-codepages, than the lis= t will forever
>> stay alive?
>
>Yes.  But its value could change if you call the function again, i= n
>which case the old value will be GC'ed at some point.
>
>> Even if the result from the function is never assigned to a variab= le
>> int the user code?
>
>Yes, even so.

Thanks.

>> 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 wor= th to copy
>> the returned list into a local list and return that so that the gl= obal list can
>> be freed so not to leak that list in the case the user does not wa= nt 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.

>> 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 d= on't
>really know.

Sounds reasonable; in that case the list should be recomputed every time.

>> 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-computin= g 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?

Yes, per above, I was just unsure if that is something constant in the
system, or can chnage during the runtime.

>I guess we want to return the list in the order the OS enumerates

MS does not state any order of enumaration for this list, and the return
value does not seem to be sorted in some order, so any code that would
actually consult this list can't rely on any order and should probably
use functions like member or find; not elt or nth.

>them, not in the reverse order.  Again, why is this important? &nb= sp;I
>don't think this function is likely to be called inside tight loops,
>is it?

Of course not. Actually I don't think myself this function will be
called much at all. Codepages are more or less pass=E9 in the world of
utf8; so that is probably old cruft that is used on old systems, or is
that still needed?
--_000_AS8PR02MB101075C8F0899BBC64608AD7396152AS8PR02MB10107eu_--