From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_ILLEGAL_IP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 22545 invoked from network); 6 Feb 2022 19:08:54 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 19:08:54 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 786A59D3AA; Mon, 7 Feb 2022 05:08:53 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AF0D49D02E; Mon, 7 Feb 2022 05:08:32 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3146D9D02E; Mon, 7 Feb 2022 05:08:30 +1000 (AEST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by minnie.tuhs.org (Postfix) with ESMTPS id C646B9D02D for ; Mon, 7 Feb 2022 05:08:27 +1000 (AEST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 2A96216057; Sun, 6 Feb 2022 20:08:25 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id E08E55E779; Sun, 6 Feb 2022 20:08:22 +0100 (CET) Date: Sun, 06 Feb 2022 20:08:22 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Bakul Shah Message-ID: <20220206190822.WUfVe%steffen@sdaoden.eu> In-Reply-To: <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org> Mail-Followup-To: Bakul Shah , Rob Pike , TUHS main list User-Agent: s-nail v14.9.23-229-gaf530c5f70 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. Subject: Re: [TUHS] more about Brian... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Bakul Shah wrote in <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org>: |Just ignore the swagger. | |I would go further than Rob in that even for sequential |programs there is no virtue in sticking to malloc/free if you |don't have to. The whole point of automation (for me) is to Well maybe. When i do perl or awk i do not even think about that memory as such exists, mostly. In so far. |delegate all the boring and repetitive work to computers so |that I can focus on more interesting things! And solving |malloc/free related bugs is boring and repetitive. For But, you know, this is a philosophy i do not like. Just like i never understood why Stroustrup gave C++ exceptions the full power of flexibility instead of allowing only a single base class but giving the entire C++ environment a toggle to produce __FILE__/__LINE__ diagnosis out of the box. Or instead of even introducing symbols which go the non-preprocessor if(XY) way and allowing access to these from within code if XY is true. So you have to invent preprocessor mess in order to be able to pass debug info down the call chain, or use non-portable ELF or so related info (which i never did). But if you do have the information at hand, your program could say #?1|kent:steffen$ s-nail -Rf /dev/empty s-nail: /dev/empty: No such entry, file or directory ... #?0!0/NONE#ERROR|:? quit ... s-nail[info]: Count cur/peek/all: 4/ 1658/ 12524 ... s-nail[info]: 0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 There are messages in the error ring, manageable via `errors' command??? s-nail[info]: 0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ????????????????E???????P?X??U??E??????? s-nail[info]: 0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 /dev/empty: No such entry, file or directory???? s-nail[info]: 0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ??X??U??????????,??????? ?X??U??,???^??? even upon receive of a signal. And this is just a silly wrapper, not even a complete thing. It is just like always, "there is no wrong weather, just the wrong clothes". |embedded code in limited space you want to use memory |carefully but for most of userland code we don't have to |worry about saving every byte. Most userland code is not real |time code (and doesn't run on realtime OSes). That doesn't |mean using memory like water -- there is a middle ground. |Don't blame the GC for incompetently programmed websites or |for layers of code using third party libraries using other |third party libraries. All the new languages [offer] [myriads] of [symbol] [annotations] in order to improve things, which also aids in giving more info to the tools. And, what is maybe more important, all programs written in these languages are written from scratch. And even if people tend to produce bugs here and there, and tend to forget the background of a problem now and then, or did not know about it when they wrote the code, ... the experience with programming has improved a lot compared to times that members of these list went through! That is of course only my personal opinion. I like C a lot (like C++ without everything but classes). --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)