From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 7C083297C8 for ; Sun, 6 Oct 2024 00:23:38 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id CE7A4425D3; Sun, 6 Oct 2024 08:23:34 +1000 (AEST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by minnie.tuhs.org (Postfix) with ESMTPS id E6B8442617 for ; Sun, 6 Oct 2024 08:23:29 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1728167006; x=1728833672; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=V2rHqlhD5miU2U6iFaOrd7C8d2s1u52xQvs9RIvl3Pc=; b=kPwYvC8RkxiVzk6gdg9gxTl9knCAhzlvxJPOE7rXp+PGzHGXXCMtJHT1xkK8QiNU+eK/zRVE ZBQS1q8XW4gBhS4Ps0lnVynOwgnIRbh1uiN5Befbeto6pTBVvz0cq4oGcKCh92SaJOkqMqlTWI 0kLCvt//mtKEki0hTDNGNJJMwliWv2jxtktQggavKbVqW1E28GYzNc5DF7bUJSb0w2wwM1gAMD wHBKF2vpPgJ+rNOi0bta2jb9aGYl1O8vpKMoUb0gEmkum5o3fNMmjjIWyA+/1OuSxV7SbF21Jb VT1lAI8m2kBIIoRCS0VPV23qX7CyAt365gB+me4ZE9uKI2VQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1728167006; x=1728833672; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=V2rHqlhD5miU2U6iFaOrd7C8d2s1u52xQvs9RIvl3Pc=; b=xmpwqiRF7zAN4XnnYJpi1C2zu9geatpCod+/DbnLfuUycv6XE+ahyIKZkJQgYIfifwiUsRth 0CaaE94VJ//NBg== Date: Sun, 06 Oct 2024 00:23:25 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Rich Salz Message-ID: <20241005222325.imlGrAhy@steffen%sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Rich Salz , The Eunuchs Hysterical Society User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: HXG5QHL4QDF2ROTHS2C6HSDRHE5U5MN3 X-Message-ID-Hash: HXG5QHL4QDF2ROTHS2C6HSDRHE5U5MN3 X-MailFrom: steffen@sdaoden.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: 30 days of awktober List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Rich Salz wrote in : |Someone is trying to write something interesting about awk every day of |this month. The thread starts here: |https://mastodon.mit.edu/@eichin/113240121988228925 The good thing is that find(1) now has + standardized. Ie his find /tmp --print0 | xargs -0 stat --format "%s %n" can now be find /tmp -exec stat --format "%s %n" {} + And the POSIX core developers mention (APPLICATION USAGE) It should be noted that using find with =E2=88=92print0 to pipe input to xargs =E2=88=92r0 is less safe than using find with =E2=88=92exec because= if find =E2=88=92print0 is terminated after it has written a partial pathname, the partial pathname may be processed as if it was a complete pathname. Heh! Other than that, off-topic to this thread i am afraid, but should be posted to another, .. but now that i am here, you know, we all owe thanks to Geoff Clare and Andrey Josey (and Eric Blake of RedHat, but really, the Linux approach to this problem makes me sick, it really should have to work as shown in RFC 2553->3493), as only thanks to these people the BSD socket API is still compatible with ISO C .. at least on POSIX systems! And here is how: In stating these field mapping requirements when a cast operator is applied to the various socket address structures, the standard defines the behavior in circumstances where the behavior is undefined in the ISO C standard. The onus is on implementations to ensure that these mappings are as described in the standard, making use of implementation-specific extensions if necessary, even though this is not stated explicitly. and the solution is On page 386 line 13115 section DESCRIPTION, change: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol=E2=80=99s address family. to: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, or vice versa, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, or vice versa, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol=E2=80=99s address family. When a pointer to a sockaddr structure is cast as a pointer to a protocol-specific address structure, or vice versa, the sa_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol=E2=80=99s address family. Additionally, the structures shall be defined in such a way that the compiler treats an access to the stored value of the sa_family_t member of any of these structures, via an lvalue expression whose type involves any other one of these structures, as permissible, despite the more restrictive expression rules on stored value access as stated in the ISO C standard. as well as this RATIONALE addition: Note that defining the sockaddr_storage and sockaddr structures using only mechanisms defined in early editions of the ISO C standard may produce aliasing diagnostics when applications use casting between pointers to the various socket address structures. Because of the large body of existing code utilizing sockets in a way that could trigger undefined behavior due to strict aliasing rules, this standard mandates that these structures can alias each other for accessing the sa_family_t member of the structures, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension, to comply with the requirements of this standard. I love this standard. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)