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=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14005 invoked from network); 10 Mar 2023 11:37:23 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 11:37:23 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 13A80413FA; Fri, 10 Mar 2023 21:37:13 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id C316A413F6 for ; Fri, 10 Mar 2023 21:37:09 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AD55518C080; Fri, 10 Mar 2023 06:37:08 -0500 (EST) To: imp@bsdimp.com, segaloco@protonmail.com Message-Id: <20230310113708.AD55518C080@mercury.lcs.mit.edu> Date: Fri, 10 Mar 2023 06:37:08 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Message-ID-Hash: C4LMNOGY7YUWXEZ37ZZU5JDPEO67EG4K X-Message-ID-Hash: C4LMNOGY7YUWXEZ37ZZU5JDPEO67EG4K X-MailFrom: jnc@mercury.lcs.mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > From: Warner Losh > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. That's because C doesn't have 'conditions'. (Apparently, from the following posts, most people here are unfamiliar with them. Too bad, they are a great idea. OK summary here: http://gunkies.org/wiki/Condition_handler for those who are unfamiliar with the idea.) I was at one point writing a compiler using a recursive descent parser, and decided the code would be a lot simpler/cleaner if I had them. (If, for example, one discovers discovers an un-expected 'end of file', there can be an extremely large number of procedure invocations in between where that is discovered, and where it is desirable to handle it. So every possible intervening procedure would have to have an 'unexpected EOF' return value, one would have to write code in every possible intervening procedure to _handle_ an 'unexpected EOF' return value, etc.)' (Yes, I could have used setjmp/longjmp; those are effectively a limited version of condition handlers.) Since C has a stack, it was relatively easy to implement, without any compiler support: on() became a macro for 'if _on("condition_name")'; _on() was a partially-assembler procedure which i) stacked the handler (I forget where I put it; I may have created a special 'condition stack', to avoid too many changes to the main C stack), and ii) patched the calling procedure's return point to jump to some code that unstacked the handler, and iii) returned 'false'. If the condition occurred, a return from _on() was simulated, returning 'true', etc. So the code had things like: on ("unexpected EOF") { code to deal with it } With no compiler support, it added a tiny bit of overhead (stacking/unstacking conditions), but not too bad. John Wroclawski and someone implemented a very similar thing entirely in C; IIRC it was built on top of setjmp/longjmp. I don't recall how it dealt with un-stacking handlers on exit (which mine did silently). Noel