From nobody Thu May 25 00:00:55 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QRSrV2j7mz4V9h4 for ; Thu, 25 May 2023 00:01:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QRSrT0sn3z3kM8 for ; Thu, 25 May 2023 00:01:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Gn1Sv3WE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684972870; bh=Be23N1nPkpakgwk3ab3gqRWJygY6PpQk3NOf5XJyYgM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Gn1Sv3WEVvLMdeW0bFzXjY1PhyaBZ+1PX8iPNiDyJ488omIVVvsmIKM78L8CYXwbSzeCq7v8+UrQtPei+VwrZSH9ZDX+AkunGNQhwuoBBVyUzVYMpL2Mn5Shvur6L+hrPSt3S3cPGPnDY3ui6Qdhm4Cftuf9PiXao8BHK4h4vwEBc0E0WWSgB8HJYfiwPBLCmuQQRDpGBN/GSveHW0/YXBAWp0xoeWBRMIdszXYo+XcmkZczhpG9GOGAVJqPcWrN3cPelXTssMXsb9tklDwCjYY8cyT+kMaU6LgO/XvPi0DBLlKfnRQPOPPRleIHqmRsz3mP7RfCEhfTkq47KLoaug== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684972870; bh=JXYDMmHz85ac6Jv6pnc/WA05qUkGXxNq01ESaaFp7m+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Yv/ab4BsKvrb5crF5OXMMvpkZYgNVK4ANZqM+0agpffuRvEUGIphHPq1WGoy3U0YaM8ArhSZsduUbhliSLZMd+Y/k6SG11Y5g9LW4WBB7GoeZavVChO1Ztz6r54TKb9n6nMDpWooGVKXy6jyUti60aU++StfqNzaIgT3+zJHa1I32ms4cZEBnxR5iNfqgQX1W/3/hKvsuC/1Jc0topMbwn7lg55qcg459p/y+ZWf3XcNF+9K7/BxeEY1hQuiHzRfk+LuNtrR42C9b/EuLZqp3Pcr1J4Tw6LlpecKopNyMaFFrd1bzpS7hwYHr5BBjFODL9GkvoK92PMGFdS8H+WY1w== X-YMail-OSG: m02rieIVM1m_bcPdyzVBRCbUSv41MDZlyKxcBn8XZohsa5YG.BdyT_Qxhgc8Mf2 VMW.XQnumJ2C8BhmNCunYM06VAlAA1NjL0mwn5TpBAANeXZaSO57n04d6_T6Un5oOUCJDZRoTu_j pDIh3Twkb5HjbZA215BF6YyJ1BFoZAj5gjL84Bf2giaovOuTYEqDEG_X1OYQnHq4Te0Ez3s_fB4P s21JeZnEkKPJqFG64IhSNzPAFAwyjf_uIIXAolXrzB1wLXLcnBbnlQMRQk9pxHq85KnScCUwwLV_ 32mR9mQ3pDzbAcsziFUgGOVMGnRSDHfxLAChmb8Kx5wnRU2iA2ciiLiw5fJaKXdzgb1qzhbSRS8L 9JSlhtTUpZIvPHzfuDQ5_bjXcQmojhWFiLE_mUc4YGkwihvSZ8W1qU_E7B0_HPxHWbNq.Gbm0AbP UJl3RchXYX90uWyKflq.V8qmoEbSOt_elKUaQa8PswyG7Fks_4bH8I0giVtSfrwZHyWmzGj32KFU Qgvp1c1ifV7xKlDpKYuK9tUSuymFZNTXm0JKGgn7fU8XJVEAoWrHwmffr1HPixLZpyYk_FIO5_6X NqCkub_KlWRaJRX6IBeddF0UENhm0eeV9BUhHMnDYZGOwBsjiQBVxtE.Wdbx4aqopInu8JC0pH5G gzV65.0nGuwFJxJBoShXzs_1617Wgl91h9Z6oCW85qmW4OPTf2J1HyWQ.RCdZkOC3qZsvjuxL88U 8iBZ96ge5NNSNjJe59UkSJxkohayHuks7ASVZi1FLV0mSwms6qAV1flLRHzcc_A0XBlID.AgTWuU 21BvhUUtcWZjQ7bDiY63nr3A_c9FhnZH.9M8MoSj0QIvDOziXKmuruwF7mjl_iOvY7mKi.N7HAP0 cExClBu4bhve7SvkldF_5K6Uq1WWfoRtFgSkt_GtZHbrsDGhvNCu13V1nDR_NmdauCHnSwo3WSYu b4iitQCj0hCAPkTFVXFelBBKuym7DFgVzU8IVigYv3Kyds1bsJdMoOY5_HLyZ8N8EL1t77zgZEJc YixCQMcjCE4pnquLNfzMPBmWphHvQXeyPJ9zOUcIoNrRJ76oKTQAxU.Q8HN33Z4zOFHxNePM2RGj D.vShcq7BsB6DwpLFL83QokwNsK6L1G8zy5QQXYL0w7oms6v.Kr1TvtIFiXihI.qV1rikRlhHiz_ 4X17vD_3Vhe3C3rClU1qGp4gTs.sIL.q5Jy1BXJuceXCHOLfhab5LUTp5U2BX..QGbbm71s8BQoC 6ZsZlwoW0nv5JdLBRPAXXdq8YDszYApEEb_PjmFJE0zR6AIzX_JyhYmjn.MEAdleYgb9pgBAXymC XHjOEK0PxDw2eT.TN3rapjhQmMAHERBc9aDSq1M4My11Zgm5cDeFT3QjvivOR3Ql.R_UxK5dUj2w Bzx2ktLvmQpjFzKF4BPUJj6ZH514qRv5SzUu4M6PWA5vDemkD5EkrLxFdTGh9SPLsB.8PvgO7znQ GUBFSOkEmr3Wp1I9NfvcILWhCqfhzYSgE8veIewn4U8De4OXzRcT1__wT6krKx0CItz8f9m7qhLo VLnLn1_4kQKs208cc37J1P0aGwWMOExDAcMjuIrO9lfwiax1cBECWTG3ahO.631ZwYX4kUpt1KHE O.DMJDgJz86R_iLT94AAKxEKyMkm45xYM5orBsemA4BU.UnwFhhknRIN2nMGadPH7kBrcdctU7lN d9ruzdrvBEM0CXt8wcBwUQbnbZ.jSnh4GNtc9L9vFGEVDFHFEbDU6wsT3thSWnT52boC1jnf9kFe EQpuDTNaBi7PDwtfW79E8_0vAgWZZefJJoF9XZmw34Rx7gNE75CnLBkixBW37Tgju7xR6JJn8ZQH IfOf3UE0FujZmqVjUaQhzvfjq3mqNZgLOCgWDlj63a9DM.J.c00r0KebinG9.qorQGthMMc0_x.x NM7xKlKIgiSatnFyUCwXoXjRSH5ovcl0..btVYSKB6EYDJFCJrKIdXtRwdga6h1SISWqJl7G.oxG Fd5CZr9G49Jtd_s4fglfIQPuLTPLlbBcVVOxIMOJ35A_sE9bG_Y_yjHC4yrfgF.lqQKv9xTEEXkG kwAWKWLUxT8_cTXPOoeOi.1FBKQGR29_QiO6cV.Lpcy.ttsaLH2ICc6fph7cnQdo1_OGMwoJesNH qZklOEB8YQ8RyjMhxHNVH3YOtXD.ABQyzNOyYtyP3EGlO8A3W4EfCoN.tbl3ugGTVHRLhRTGxPgQ K2HUjA5nW0V1XDTvY5CbvHU83RMd8UVBx2aqV0OkhVKHoVP1Jf57OZbjfXnyveU09V1XsIIetF7f atw-- X-Sonic-MF: X-Sonic-ID: 67254d2c-63e5-4be1-ad00-ec762b2ef9a4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 May 2023 00:01:10 +0000 Received: by hermes--production-gq1-6db989bfb-ppvpv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b4bf33793be5647c186f1b5e03b91dbc; Thu, 25 May 2023 00:01:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD From: Mark Millard In-Reply-To: <9C0CE0A5-150D-4FE1-A838-F1E6A39960F6@yahoo.com> Date: Wed, 24 May 2023 17:00:55 -0700 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <204FCA67-3FCD-48BA-A373-ABE8AD915D40@yahoo.com> References: <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4.ref@yahoo.com> <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4@yahoo.com> <6293f06b-927f-432a-3911-808b1d99441b@selasky.org> <9C0CE0A5-150D-4FE1-A838-F1E6A39960F6@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.870]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4QRSrT0sn3z3kM8 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 24, 2023, at 09:52, Mark Millard wrote: > On May 22, 2023, at 13:16, Mark Millard wrote: >=20 >> On May 22, 2023, at 03:00, Hans Petter Selasky = wrote: >>=20 >>> On 5/22/23 01:07, Mark Millard wrote: >>>> In the C language standard, the original had a status of "no = linkage" >>>> and "static storage duration". ("a block scope identifier >>>> for an object declared without the storage-class specifier >>>> extern" leads to the "no linkage" status.) >>>> The change still has "static storage duration" but now has = "internal >>>> linkage" status instead. I'm being cautious about the distinction. >>>> (I'm looking at ISO/IEC 9899:2011 (E).) >>>> I've had trouble identifying the match of your wordings to the >>>> language standard, leaving me unsure of the interpretation to >>>> give your wording. >>>> I've yet to figure out why internal linkage could end up >>>> being required, given how the language specifies things. >>>=20 >>> Hi, >>>=20 >>> If you find something, let me know. I'll let the issue rest for some = days. >>=20 >> Okay. File the below for later. >>=20 >> (Some detailed whitespace below might not survive.) >>=20 >>=20 >> I still find no reason in the C11 standard to change >> the code in question from: >>=20 >> Block Scope, No Linkage, Static Storage Duration >>=20 >> into: >>=20 >> File Scope, Internal Linkage, Static Storage Duration >>=20 >> I'll ponder the standard's text some more but I doubt >> that I'll find something that I've missed so far. >>=20 >>=20 >> I propose using 2 source files that I show below as >> the basis for terminology. I set them up based on >> text from the C11 standard. If you can explain why >> Internal Linkage would be required in terms of some >> similar example and terminology, it would help be >> sure I'm not missing something that you are >> referencing. >>=20 >> (Part of the text was just me trying to make sure that >> I'd appropriately covered the allowed combinations of >> official language concepts that are involved.) >>=20 >>=20 >> # more NameScope_Linkage_StorageDuration_combinations.c >> // For -std=3Dc99 or c11 or c17 or c2x (showing c99): >>=20 >> // cc -std=3Dc99 -pedantic -Wall -Wextra -c = FileScope_ExternalLinkage_initialization.c >> // cc -std=3Dc99 -pedantic -Wall -Wextra = NameScope_Linkage_StorageDuration_combinations.c = FileScope_ExternalLinkage_initialization.o >> // ./a.out >>=20 >> // gcc13 -std=3Dc99 -pedantic -Wall -Wextra -c = FileScope_ExternalLinkage_initialization.c >> // gcc13 -std=3Dc99 -pedantic -Wall -Wextra = NameScope_Linkage_StorageDuration_combinations.c = FileScope_ExternalLinkage_initialization.o >> // ./a.out >>=20 >>=20 >> // Indentification of contexts and the subset covered here: >>=20 >> // Just objects (not macros, functions, tags, typedefs names, lables, = etc.): >> // (Note: function prototype scope is not relevant here) >> // >> // Scopes (visibility): Block, File >> // Linkages: None (No), External, Internal >> // Storage durations: Automatic, Static (, Thread, Allocated) >> // Name space: Ordinary Identifiers (Note: no = alternatives) >>=20 >> // Note: I do not cover any thread-storage-duration related contexts = here. >> // Note: I do not cover any allocated-storage-duration contexts here. >>=20 >> // Note: I do not cover the special non-lvalue expression contexts = here >> // that involve the combination: >> // temporary-lifetime and automatic-storage-duration >>=20 >> // For reference: >> // Static Storage Duration: "Its lifetime is the entire execution of = the >> // program and its storage value is = initialized >> // only once, prior to program startup." >> // >> // It need not be tied to file scope or to external/internal linkage. >>=20 >> // Covered here: >> // Block Scope, No Linkage, Automatic Storage Duration >> // Block Scope, No Linkage, Static Storage Duration >> // Block Scope, External Linkage, Static Storage Duration >> // File Scope, Internal Linkage, Static Storage Duration >> // File Scope, External Linkage, Static Storage Duration >>=20 >> // Note: Only external linkage objects have a definition vs. >> // declaration distinction. >>=20 >> // I count 4 distinct non-stack types of whole-program-lifetime >> // object contexts in that list: The static-storage-duration ones. >> // But: >> // >> // Block Scope, External Linkage, Static Storage Duration >> // >> // can only be used to declare access to an external-linkage >> // defined elsewhere (defined outside any block scope). >>=20 >> // Note: There is no such thing as the combination: >> // Block Scope, Internal Linkage, Static Storage Duration >>=20 >> // Note: "Each declaration of an identifier with no linkage >> // denotes a unique entity." This prevents various >> // forms of multiple declarations for the same >> // namespace and scope combination. >>=20 >> #include >>=20 >> // Note: Only automatic storage duration is in a call stack. >> int Using_BlockScope_NoLinkage_AutomaticStorageDuration(void) >> { >> int BlockScope_NoLinkage_AutomaticStorageDuration =3D 1; >> return ++BlockScope_NoLinkage_AutomaticStorageDuration; >> } >>=20 >> // Note: No direct notation for file scope access exists but >> // the storage duration spans when the function is not >> // in use. >> int Using_BlockScope_NoLinkage_StaticStorageDuration(void) >> { >> static int BlockScope_NoLinkage_StaticStorageDuration =3D 1; >> return ++BlockScope_NoLinkage_StaticStorageDuration; >> } >>=20 >> int Using_BlockScope_ExternalLinkage_StaticStorageDuration(void) >> { >> // Note: Defined/initialized in = FileScope_ExternalLinkage_initialization.c >> // Such an external definition is not allowed in block scope. >> extern int ExternalLinkage_StaticStorageDuration; // a declaration >> return ++ExternalLinkage_StaticStorageDuration; >> } >>=20 >> // Note: To have internal linkage requires a file scope declaration. >> static int FileScope_InternalLinkage_StaticStorageDuration =3D 1; >> // Note: after such an internal linkage definition, the following >> // is allowed (not required) but does not change the status. >> // "extern" does not always mean external-storage-duration. >> extern int FileScope_InternalLinkage_StaticStorageDuration; >> int Using_FileScope_InternalLinkage_StaticStorageDuration(void) >> { >> // Note: after such an internal linkage definition, the following >> // is allowed (not required) but does not change the status. >> // "extern" does not always mean external-storage-duration. >> extern int FileScope_InternalLinkage_StaticStorageDuration; >>=20 >> return ++FileScope_InternalLinkage_StaticStorageDuration; >> } >>=20 >> // Note: Defined/initialized in = FileScope_ExternalLinkage_initialization.c >> extern int FileScope_ExternalLinkage_StaticStorageDuration; // a = declaration >> // Note: Without "extern", a definition would be allowed above, = instead >> // of having one in FileScope_ExternalLinkage_initialization.c = . >> int Using_FileScope_ExternalLinkage_StaticStorageDuration(void) >> { >> return ++FileScope_ExternalLinkage_StaticStorageDuration; >> } >>=20 >> int main(void) >> { >> (void) Using_BlockScope_NoLinkage_AutomaticStorageDuration(); >> printf("Using_BlockScope_NoLinkage_AutomaticStorageDuration() : = %d (expect 2)\n" >> , Using_BlockScope_NoLinkage_AutomaticStorageDuration()); >>=20 >> (void) Using_BlockScope_NoLinkage_StaticStorageDuration(); >> printf("Using_BlockScope_NoLinkage_StaticStorageDuration() : = %d (expect 3)\n" >> , Using_BlockScope_NoLinkage_StaticStorageDuration()); >>=20 >> (void) Using_BlockScope_ExternalLinkage_StaticStorageDuration(); >> printf("Using_BlockScope_ExternalLinkage_StaticStorageDuration(): = %d (expect 3)\n" >> , Using_BlockScope_ExternalLinkage_StaticStorageDuration()); >>=20 >> (void) Using_FileScope_InternalLinkage_StaticStorageDuration(); >> printf("Using_FileScope_InternalLinkage_StaticStorageDuration() : = %d (expect 3)\n" >> , Using_FileScope_InternalLinkage_StaticStorageDuration()); >> printf("Accessing FileScope_InternalLinkage_StaticStorageDuration : = %d (expect 3 again)\n" >> , FileScope_InternalLinkage_StaticStorageDuration); >> } >>=20 >>=20 >> # more FileScope_ExternalLinkage_initialization.c >> // For -std=3Dc99 or c11 or c17 or c2x (showing c99): >>=20 >> // cc -std=3Dc99 -pedantic -Wall -Wextra -c = NameScope_Linkage_StorageDuration_combinations.c >>=20 >> // gcc13 -std=3Dc99 -pedantic -Wall -Wextra -c = NameScope_Linkage_StorageDuration_combinations.c >>=20 >> // Defined at file scope here. >> // Used separately at block scope elsewhere. >> // The definition can not be in block scope. >> int ExternalLinkage_StaticStorageDuration =3D 1; // a definition >>=20 >> // Defined at file scope here. >> // Used separately at file scope elsewhere. >> int FileScope_ExternalLinkage_StaticStorageDuration =3D 1; // a = definition >>=20 >=20 > It has been a few days. So I'll add the following. >=20 > Stepping outside the language definition, in > case you are curious about an example of how: >=20 > Block Scope, No Linkage, Static Storage Duration >=20 > can be handled by a toolchain, in a FreeBSD > main aarch64 context I get: >=20 > # nm a.out | grep Linkage > 0000000000410c7c d BlockScope_NoLinkage_StaticStorageDuration.0 > 0000000000410c80 D ExternalLinkage_StaticStorageDuration > 0000000000410c84 D FileScope_ExternalLinkage_StaticStorageDuration > 0000000000410c78 d FileScope_InternalLinkage_StaticStorageDuration > 00000000004005e4 T = Using_BlockScope_ExternalLinkage_StaticStorageDuration > 0000000000400594 T Using_BlockScope_NoLinkage_AutomaticStorageDuration > 00000000004005b8 T Using_BlockScope_NoLinkage_StaticStorageDuration > 000000000040063c T = Using_FileScope_ExternalLinkage_StaticStorageDuration > 0000000000400610 T = Using_FileScope_InternalLinkage_StaticStorageDuration >=20 > "BlockScope_NoLinkage_StaticStorageDuration.0" is not a valid > C identifier but has a structure allowing making each such: >=20 > Block Scope, No Linkage, Static Storage Duration >=20 > unique when the identifier part is not: replacing the 0 in .0 > with other numerals, incrementing values, say. The "d" status > avoids it being external. >=20 > Overall, then there is nothing else having a possible linkage: > "linkage none" in the C11 standard's terms. I took a look at a . . ./sys/modules/mlx4/mlx4_main.o via nm and it showed a different convention for creating uniqueness for the type of context involved: static ssize_t set_port_type(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { . . . static DEFINE_MUTEX(set_port_type_mutex); . . . ended up with the static routine's name prefixed, with a "." separator: 0000000000006da0 t set_port_type 0000000000000018 d = set_port_type.__set_sysinit_set_sym_set_port_type_mutex_sx_sysinit_sys_ini= t 0000000000000008 d = set_port_type.__set_sysuninit_set_sym_set_port_type_mutex_sx_sysuninit_sys= _uninit 0000000000000020 b set_port_type.set_port_type_mutex 00000000000004a8 d set_port_type.set_port_type_mutex_args 00000000000004c0 d set_port_type.set_port_type_mutex_sx_sysinit_sys_init 00000000000004d8 d = set_port_type.set_port_type_mutex_sx_sysuninit_sys_uninit This was based on: # uname -apKU # long output line manually split for readability FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #94 main-n262658-b347c2284603-dirty: Fri Apr 28 19:57:23 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400088 1400088 and so the context predates any changes. =3D=3D=3D Mark Millard marklmi at yahoo.com