From nobody Wed May 24 16:52:59 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 4QRHLl1W7Mz4TGxQ for ; Wed, 24 May 2023 16:53:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4QRHLk0gkQz49P2 for ; Wed, 24 May 2023 16:53:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="KQ/f1dUG"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 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=1684947196; bh=VmtgQYMBJOuJp4xS7RyZwfnZPHNsR5s09acbXqbYkoc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KQ/f1dUGbpnAZ8VDNzsdh+vYgNPStDiZ53kH9wURAbkA5dvSrh7r+a6L2vwsWlLYkd2DXFwpbZ5eIk7OLNPXhCoaQICZC3YWtcP/CGBssFTuR4ErgDkP+JvNFeLwTlJ5ZZMpnuMfW0867vYrlW2leDWJpr8TWrzFKK/UE6ubU7RJfbVDOj9/BIIYZ2PGEcmLA44RJeqGK5SZvdKMIsGU0CBGaXrN0SoAG4xCkK0IS8/AYvq25AZdNXJN0C0V6vvj0o/niNumQoIA+ktGgXeS1uSKohpl2puxZFe37EMhQgqphmVBDx3JPTmAqm5Ltg6gnkR2nLs5YdVH+lUH1mYSeg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684947196; bh=HJt/QjWfsmAULNE6GbvGI4bIqUY68BrD3SsRxcKlC6n=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qnCCCVrhKuMOgbRNz9tOaP8UecBYWx/IMJO2da20RbWexyc+OT83r7Ku7onPRkELR+oxLf3KPYNm133RczgaT9DjxlJVmUQmjLPxeDqPsMO9AWcfm7Av0AZVtjuDlCdKYl1l1sfaucJ04VGxo7mNWXhIcYdMMwWkrj8t2pJCLTwOOSlELwqkOBXuZzmWn+PhB//+sEBoTRyTBphjPyEUKmmIomSALEchwHqgTe+PZYkIHnNiwIvv5g4SI4dySFGgNBINqyP6XUkUMJXmcq7aLb5nzr2Rb9v/ps1Ip5q+bEIWj2galZC+vAvceWHs7S20S87Y77TGMNdcMZ/I0ikKCA== X-YMail-OSG: hIcKWHcVM1ng5PPse11OLCkGrS.ZpVBfEVAJCC.u0ZtYJxrQbaMpZsHTfcrcm_A wUXXa9FHCRVX4BdQFHkw2ck5i1iqp6NkEvJUaZjDMZ7aJ4K8J9VeE3xaEz3iifLYRtQyg.F3E7sd R7kHl18zTD.or.9j9TW_FWLMfvbYpn3mvAC7Eevqr2SpKypokcWNufUUgC4psXgWGPirDg4C2Lju JbcQXeVpKYWJPtSWULZpjrqH0XNE6az2q8J5KATNWZeWRTRnO.xtgwoZWEaZ2gpOWiK732rIoyup 8XkoHg5FFJcE4pXRnUq5tpD1Bkwg3IBS01jtNndzFfbrvZTnXU0javY8GpVJx.MUEum6Svqwf3Oj 5rvXwYNgEvXBu.i1LOP9gApynI0t8w_8MrGTbIbPkGUTDmrV.uB3_z.vy.WSTADrQtYwV.LktP_l z17QNqAhZpBGvcvisWNFngtSPWIBzIWaB7cDVz5zPgKlGcirgBfYIYxqpsctvN_jtKj0_1Vl57yg nHnvwEJjv0MklzQ2wGFnFYsu9RJW29enfa066clxHJvkQUyhiH.bv7MonjfmTcaaV51rfLaPPaC6 ahcDd0kJta51uPWMWENamRVcqqd8wwMEbFxVUJ1Tqg_1Y9MaV7oMVI0jaxNTqSrIEPDi2AKT2vLp MAL9c1uHcsdvnN3UZeSNLWOAJkzjc2CYvwJbEghS48..LGriyTTCYMZkbVLh9V7GnPl8LvtLkK4n e11Ov39yhLWlnhXE9mcsDLIkPITTEB.7BuksSn6qD8_qnAELZG2TNoSECVc0aHvRQJb6vmmSFZMF 6ZPgd4wte8IE099lZuUCjE1RO6oebyjiPAsr0Z4fLIBY7ZNNdPP8ehY1OMVT5Zr7zPx10L_gUw3I M6Fa1mhGnKb8y.zyqob0pGRVGtAWEdCz3kn5X74pIIQt1J665iZFfMRQNr47uKq2PZw73clkFPvN cozNe30HZK5USbAgLZ8DcJgUOggw_JdRatEKeSuc.YIuHzecWc956E46bmg5R9GWMoJEV_xApRVm _t3AxHakIsiMbCzxAFJ6MZWZ7xcLtsA.iFiWTuzfPWEcqw1oknuBCVeGsh8sOfM9536HvE__X53b mmiBzZ4Mm2J1rjlisCpnD3r7ODAWAFVq9RqKfL4xfRHkVuWS69ARuZko3rksiWGoj9vcvME5tUon ARFkBQQskQwmiFlErEzkaFKW1rgUWo0gHOhkxV2DlbSHkHkGkpipxX7fRYp3F67wGhYbrZEkw.nR qOZDKqwWYOTpMn34ANy0apEQ6_aU9nyFdRpS3gNkSsVqzaNRqUKLaE8SVig2ymB8z7.bcb7hxA4M idJ22dkR7YF25rfpFHxHF3MTGsyc6TnKt5b3aUC2kJLQH_8a5TXrqFPhTqSgVX693TRIMO5gGnpC DO3HqazkeYapB21xn13zqPn0myZfis2Z0DtxQUIXu1DKW2vTQns8MnYYa8lKK3NXrUqlOE5XbO.c Cj3SKoYSVDh8KSoZaxE3M6XD1gupK7bRbvRz8EwqI2mhSq_QLhuwsc3bm9gco44Q9gpGCd9JpRcI 6NOdlAuC.6oyoXdkszHhPKQ.HpUBF.3FbAC9MbCr7uPKA4aGHQErrQnEf3VWNnhAFDIMx8u4dQ5c 1Zdqekcg0FbOBhLSk2gODVGQp60bfhXX3Z.6gB9u_7UrbTaQ_R_1kf7H9CdBqZOauqejYH693ESH fhQfJswwFgEwRF2pOpAFkc5Ni9p0mpom9_xWfheZQoL_bOaEE9oPAl4T5h4Nz99fp9RYppDIcCnt v1iQiKGLMz99Uzn_BMCRya3JaLzrkGSxDEC9MLxfl1m1d48gNIU5c_nR5NfMDI5cjmSoILO0lE9H _OinosFovzjaqInpJiUcJ85lU.vqtTrKQaVuwinSaGzwaLYjRaeQhHxCzegXlPd6_chNx8nHn8TC Y1Da3yr4JHbgLf6Ldh6.CtBXq901qdI8_lyrtbCP0dQzW_r_AK2Fhd4xCu18hQv0LcnA6_qV.qzN qtn54e6xb_.m9dvbNjq_Bsk99OekGMw.A2yjQekiPXCL.0VS6vQzOgKDFWr4PiAKfOh01MrmonJp JGNFgybJaifbF_seEXSLqii60uEYg26Jf2u3n9aSIHgElfIBZpmE0ZqwupefkYbqtRFlKNA0j0T1 4llL7r4FpTagT0SNgKKp69m1WF.eESY4DtEBYMqbzRhu_xReSZcGiH5Ls7FNVO8pCiOCFXm5jlEX PKXkSEgSd6LzPDTpja8VwPByeMEPkBqP5hYI0G9y92Cs47HNsGYlRDcCpOVH_Fmctmuvtpkd.vYP EyOA- X-Sonic-MF: X-Sonic-ID: eedadd2e-d17b-4d46-991d-baafa6bcab8d Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 May 2023 16:53:16 +0000 Received: by hermes--production-ne1-574d4b7954-6wwdb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d5d4bc4124a708185af64a64bcb1601f; Wed, 24 May 2023 16:53:11 +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: Date: Wed, 24 May 2023 09:52:59 -0700 Cc: freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <9C0CE0A5-150D-4FE1-A838-F1E6A39960F6@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> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; 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.30: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.30:from] X-Rspamd-Queue-Id: 4QRHLk0gkQz49P2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On May 22, 2023, at 13:16, Mark Millard wrote: > 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 It has been a few days. So I'll add the following. Stepping outside the language definition, in case you are curious about an example of how: Block Scope, No Linkage, Static Storage Duration can be handled by a toolchain, in a FreeBSD main aarch64 context I get: # 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 "BlockScope_NoLinkage_StaticStorageDuration.0" is not a valid C identifier but has a structure allowing making each such: Block Scope, No Linkage, Static Storage Duration 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. Overall, then there is nothing else having a possible linkage: "linkage none" in the C11 standard's terms. =3D=3D=3D Mark Millard marklmi at yahoo.com