[TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary

[TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary

[Steffen Nurpmeso]

I wonder if Pink Floyd's Summer68 maybe refers to this.
Other than that i am addicted and could not live without it.
The other (terrible) song is from 1984 (east southern US).

--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)

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[segaloco via TUHS]

GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs...

Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do?  Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs?  Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right.  Any alternative camps out there?

- Matt G.

------- Original Message -------
On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:


> I wonder if Pink Floyd's Summer68 maybe refers to this.
> Other than that i am addicted and could not live without it.
> The other (terrible) song is from 1984 (east southern US).
> 
> --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)

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> GOTO is one of those paradoxical things where I would only trust the most
> sophisticated engineer to know when it's acceptable to use a GOTO but on
> the flip side would be suspicious of anyone claiming to be an engineer that
> uses any amount of GOTOs...
>
> Were any of the various GOTOs in languages ever meant to be any more than
> providing the same level of control that branch statements in assembly do?
> Was there ever some vision anyone's aware of concerning a sophisticated,
> dependable use of GOTOs?  Since my first days poking around learning C GOTO
> has been mentally filed away as an assembly vestige for folks in
> transition, not a dependable construct in its own right.  Any alternative
> camps out there?
>


In C I use it all the time to do goto err for common error recovery because
C doesn't have anything better.

Warner

> - Matt G.
>
> ------- Original Message -------
> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso <
> steffen@sdaoden.eu> wrote:
>
>
> > I wonder if Pink Floyd's Summer68 maybe refers to this.
> > Other than that i am addicted and could not live without it.
> > The other (terrible) song is from 1984 (east southern US).
> >
> > --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)
>

[-- Attachment #2: Type: text/html, Size: 2174 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Luther Johnson]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

I agree, unless I use setjmp/longjmp for that. Besides error recovery, 
there are occasionally other times when we want to locally "return" to a 
common state and start "from the top" again. I find such uses very clear 
in their intent, and if commented well, not hard to follow at all - as 
long as there is not more than one "top" :)

On 03/09/2023 04:21 PM, Warner Losh wrote:
>
>
> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS <tuhs@tuhs.org 
> <mailto:tuhs@tuhs.org>> wrote:
>
>     GOTO is one of those paradoxical things where I would only trust
>     the most sophisticated engineer to know when it's acceptable to
>     use a GOTO but on the flip side would be suspicious of anyone
>     claiming to be an engineer that uses any amount of GOTOs...
>
>     Were any of the various GOTOs in languages ever meant to be any
>     more than providing the same level of control that branch
>     statements in assembly do?  Was there ever some vision anyone's
>     aware of concerning a sophisticated, dependable use of GOTOs? 
>     Since my first days poking around learning C GOTO has been
>     mentally filed away as an assembly vestige for folks in
>     transition, not a dependable construct in its own right.  Any
>     alternative camps out there?
>
>
>
> In C I use it all the time to do goto err for common error recovery 
> because C doesn't have anything better.
>
> Warner
>
>     - Matt G.
>
>     ------- Original Message -------
>     On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso
>     <steffen@sdaoden.eu <mailto:steffen@sdaoden.eu>> wrote:
>
>
>     > I wonder if Pink Floyd's Summer68 maybe refers to this.
>     > Other than that i am addicted and could not live without it.
>     > The other (terrible) song is from 1984 (east southern US).
>     >
>     > --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)
>


[-- Attachment #2: Type: text/html, Size: 3893 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[josh]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

This blog post compares the clarity of a number of programs written
with goto vs. with other control flow methods:
https://blog.joren.ga/gotophobia-harmful

Knuth’s “Structured Programming with go to Statements” argues that we
eventually missed the main point of structured programming by focusing too
much on goto. https://pic.plover.com/knuth-GOTO.pdf

Error handling (especially in loops or when releasing resources in non-RAII
languages) and implementing state machines are commonly brought up as cases
where goto is more fitting than common “structured” control flow
statements. I think some newer languages like Zig extend the “break”
mechanism to let you break to a label, so that sort of covers the first
case.

Josh

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Oh also sometimes for breaking out of multiple levels of while/for loops.
The alternatives are often worse.

Warner

On Thu, Mar 9, 2023, 4:31 PM Luther Johnson <luther@makerlisp.com> wrote:

> I agree, unless I use setjmp/longjmp for that. Besides error recovery,
> there are occasionally other times when we want to locally "return" to a
> common state and start "from the top" again. I find such uses very clear in
> their intent, and if commented well, not hard to follow at all - as long as
> there is not more than one "top" :)
> On 03/09/2023 04:21 PM, Warner Losh wrote:
>
>
>
> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> GOTO is one of those paradoxical things where I would only trust the most
>> sophisticated engineer to know when it's acceptable to use a GOTO but on
>> the flip side would be suspicious of anyone claiming to be an engineer that
>> uses any amount of GOTOs...
>>
>> Were any of the various GOTOs in languages ever meant to be any more than
>> providing the same level of control that branch statements in assembly do?
>> Was there ever some vision anyone's aware of concerning a sophisticated,
>> dependable use of GOTOs?  Since my first days poking around learning C GOTO
>> has been mentally filed away as an assembly vestige for folks in
>> transition, not a dependable construct in its own right.  Any alternative
>> camps out there?
>>
>
>
> In C I use it all the time to do goto err for common error recovery
> because C doesn't have anything better.
>
> Warner
>
>> - Matt G.
>>
>> ------- Original Message -------
>> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso <
>> steffen@sdaoden.eu> wrote:
>>
>>
>> > I wonder if Pink Floyd's Summer68 maybe refers to this.
>> > Other than that i am addicted and could not live without it.
>> > The other (terrible) song is from 1984 (east southern US).
>> >
>> > --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)
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4151 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[segaloco via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

I guess I hadn't considered deeply nested loops. I contort myself into a mental pretzel figuring out how to avoid GOTOs sometimes, maybe I could stand to embrace one every once in a while myself...

Now doing some research, more languages support GOTO than I thought, including C#, PHP, even Rust for all its safety orientation appears to at least muster a GOTO-ish construct. If people keep doing it, it must still be wanted, needed, and useful. I stand corrected on my never-GOTO attitude. Now to slip a GOTO into a work project and see how long it takes to get chastised :)

- Matt G.
------- Original Message -------
On Thursday, March 9th, 2023 at 3:54 PM, Warner Losh <imp@bsdimp.com> wrote:

> Oh also sometimes for breaking out of multiple levels of while/for loops. The alternatives are often worse.
>
> Warner
>
> On Thu, Mar 9, 2023, 4:31 PM Luther Johnson <luther@makerlisp.com> wrote:
>
>> I agree, unless I use setjmp/longjmp for that. Besides error recovery, there are occasionally other times when we want to locally "return" to a common state and start "from the top" again. I find such uses very clear in their intent, and if commented well, not hard to follow at all - as long as there is not more than one "top" :)
>>
>> On 03/09/2023 04:21 PM, Warner Losh wrote:
>>
>>> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>>
>>>> GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs...
>>>>
>>>> Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do? Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs? Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right. Any alternative camps out there?
>>>
>>> In C I use it all the time to do goto err for common error recovery because C doesn't have anything better.
>>>
>>> Warner
>>>
>>>> - Matt G.
>>>>
>>>> ------- Original Message -------
>>>> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>>>>
>>>>> I wonder if Pink Floyd's Summer68 maybe refers to this.
>>>>> Other than that i am addicted and could not live without it.
>>>>> The other (terrible) song is from 1984 (east southern US).
>>>>>
>>>>> --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)

[-- Attachment #2: Type: text/html, Size: 5408 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

On Thu, Mar 9, 2023, 5:55 PM segaloco <segaloco@protonmail.com> wrote:

> I guess I hadn't considered deeply nested loops. I contort myself into a
> mental pretzel figuring out how to avoid GOTOs sometimes, maybe I could
> stand to embrace one every once in a while myself...
>

Yea. I recall a proposal to add break label; and the label could only be at
the end of a loop. The objection was why bloat the compiler with another
goto... I developed my restricted lack of fear after a stint in Java with
its multilevel break...

Warner


Now doing some research, more languages support GOTO than I thought,
> including C#, PHP, even Rust for all its safety orientation appears to at
> least muster a GOTO-ish construct. If people keep doing it, it must still
> be wanted, needed, and useful. I stand corrected on my never-GOTO attitude.
> Now to slip a GOTO into a work project and see how long it takes to get
> chastised :)
>
> - Matt G.
> ------- Original Message -------
> On Thursday, March 9th, 2023 at 3:54 PM, Warner Losh <imp@bsdimp.com>
> wrote:
>
> Oh also sometimes for breaking out of multiple levels of while/for loops.
> The alternatives are often worse.
>
> Warner
>
> On Thu, Mar 9, 2023, 4:31 PM Luther Johnson <luther@makerlisp.com> wrote:
>
>> I agree, unless I use setjmp/longjmp for that. Besides error recovery,
>> there are occasionally other times when we want to locally "return" to a
>> common state and start "from the top" again. I find such uses very clear in
>> their intent, and if commented well, not hard to follow at all - as long as
>> there is not more than one "top" :)
>> On 03/09/2023 04:21 PM, Warner Losh wrote:
>>
>>
>>
>> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>
>>> GOTO is one of those paradoxical things where I would only trust the
>>> most sophisticated engineer to know when it's acceptable to use a GOTO but
>>> on the flip side would be suspicious of anyone claiming to be an engineer
>>> that uses any amount of GOTOs...
>>>
>>> Were any of the various GOTOs in languages ever meant to be any more
>>> than providing the same level of control that branch statements in assembly
>>> do? Was there ever some vision anyone's aware of concerning a
>>> sophisticated, dependable use of GOTOs? Since my first days poking around
>>> learning C GOTO has been mentally filed away as an assembly vestige for
>>> folks in transition, not a dependable construct in its own right. Any
>>> alternative camps out there?
>>>
>>
>>
>> In C I use it all the time to do goto err for common error recovery
>> because C doesn't have anything better.
>>
>> Warner
>>
>>> - Matt G.
>>>
>>> ------- Original Message -------
>>> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso <
>>> steffen@sdaoden.eu> wrote:
>>>
>>>
>>> > I wonder if Pink Floyd's Summer68 maybe refers to this.
>>> > Other than that i am addicted and could not live without it.
>>> > The other (terrible) song is from 1984 (east southern US).
>>> >
>>> > --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)
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6312 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Rich Morin]

> On Mar 9, 2023, at 15:18, segaloco via TUHS <tuhs@tuhs.org> wrote:
> 
> GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs...
> 
> Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do?  Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs?  Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right.  Any alternative camps out there?

COBOL's ALTER statement is kind of analogous to a computed GOTO, but it adds a dangerous aspect of "action at a distance" (i.e., monkey-patching which invisibly modifies the control flow of the original code):

	"The ALTER statement changes the transfer point specified in a GO TO statement"
	https://www.mainframebug.com/tuts/COBOL/module7/Top18_COBOL_ALTER_statement.php

	"The ALTER Statement"
	https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHPDF803.html

The problem, IMO, is that the compile-time program flow can be invisibly altered at run time, by code anywhere else in the program.  So, there is no requirement that a given branch, GOTO, or noop statement will have its compile-time semantics.  If used with restraint, this be used to optimize code paths, but it can easily be overused.  

Just as a GOTO is a surfacing of the assembler branch instruction(s), the ALTER is analogous to an old assembly-language trick (aka hack): dynamically modifying "br*/noop foo" commands.  FWIW, I didn't use either the ALTER or the trick in my own code, but I did keep them in reserve (:-).

In one of my earliest COBOL projects, the code came to me with an infestation of ALTER statements: specifically, a hierarchy of IF statements with ALTER statements at various levels.  This was used at startup time, to configure the remainder of the program.  All very elegant, but really overkill for the task at hand.

As I explained to my boss, the ALTER statements made the code really difficult to understand.  With his permission, I removed the nest of ALTERs and reworked the remaining control flow as needed.  I was greatly assisted in this by the fact that I could retain the DATA DIVISION as-is, and merely implement the (rather prosaic) control flow that we actually used.

And no, I don't want to return to either assembler or COBOL (:-).

-r

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Dave Horsfall]

On Thu, 9 Mar 2023, Warner Losh wrote:

> In C I use it all the time to do goto err for common error recovery 
> because C doesn't have anything better.

<AOL>
Me too :-)
</AOL>

Seriously, I also use setjmp()/longjmp() for a more elegant exit from a 
deeply-nested loop; "break N" to break out of "N" loops, anyone?  I 
haven't found that yet...

Of course, in those days it was setexit() etc :-)

-- Dave

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Ralph Corderoy]

Hi Werner,

> after a stint in Java with its multilevel break...

Given sh(1)'s break takes an optional number of loops to break out of,
I'm surprised C stuck with just the single-level break.

-- 
Cheers, Ralph.

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[arnold]

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Werner,
>
> > after a stint in Java with its multilevel break...
>
> Given sh(1)'s break takes an optional number of loops to break out of,
> I'm surprised C stuck with just the single-level break.

C predates the Bourne shell by several years. Remember too that the
C compiler had to fit in a small space; having multilevel or labelled
breaks requires more bookkeeping.

The idea of labelled loops is not at all new, Ada had them in the 80s
and it wasn't new then. IIRC Go also provides them.

Arnold

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Ralph Corderoy]

Hi Arnold,

> > > after a stint in Java with its multilevel break...
> >
> > Given sh(1)'s break takes an optional number of loops to break out of,
> > I'm surprised C stuck with just the single-level break.
>
> C predates the Bourne shell by several years.

Yes, but C was evolving.  As it aged and spread in use, I agree it could
change less easily.

> Remember too that the C compiler had to fit in a small space; having
> multilevel or labelled breaks requires more bookkeeping.

Is it more bookkeeping than is already needed to handle the ends of the
nested for-loops, say?

-- 
Cheers, Ralph.

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[arnold]

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> > Remember too that the C compiler had to fit in a small space; having
> > multilevel or labelled breaks requires more bookkeeping.
>
> Is it more bookkeeping than is already needed to handle the ends of the
> nested for-loops, say?

Yes, since you have to keep track of a label in a table somewhere
that you can look up. Is it *that* much more that the PDP-11 C compiler
could not have handled it? I don't know.

Arnold

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Ralph Corderoy]

Hi Arnold,

> > > Remember too that the C compiler had to fit in a small space;
> > > having multilevel or labelled breaks requires more bookkeeping.
> >
> > Is it more bookkeeping than is already needed to handle the ends of
> > the nested for-loops, say?
>
> Yes, since you have to keep track of a label in a table somewhere that
> you can look up.

Oh, I think our wires are crossed.

I wrote:
> Given sh(1)'s break takes an optional number of loops to break out of,
> I'm surprised C stuck with just the single-level break.

In other words, ‘break 2’ works in sh but not in C.

You added labelled breaks; I wasn't asking if they upped the
housekeeping, just ‘break 2’.

-- 
Cheers, Ralph.

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Steffen Nurpmeso]

Dave Horsfall wrote in
 <alpine.BSF.2.21.9999.2303101657460.4881@aneurin.horsfall.org>:
 |On Thu, 9 Mar 2023, Warner Losh wrote:
 |> In C I use it all the time to do goto err for common error recovery 
 |> because C doesn't have anything better.
 |
 |<AOL>
 |Me too :-)
 |</AOL>
 |
 |Seriously, I also use setjmp()/longjmp() for a more elegant exit from a 

That is sheer unbelievable, really?  _So_ expensive!

 |deeply-nested loop; "break N" to break out of "N" loops, anyone?  I 
 |haven't found that yet...

Very often i find myself needing a restart necessity, so "continue
N" would that be.  Then again when "N" is a number instead of
a label this is a (let alone maintainance) mess but for shortest
code paths.

All the "replacements", like closures, plain inner functions, even
more contorted conditionals (i think in the last seven days i saw
at least three fixes fly by due to logic errors in contorted
conditionals, tiny C compiler, OpenBSD i think bpf/bgpd?, and some
FreeBSD commit, which sums up as "Pascal: no"), and "state machine
indicating variables" are not as elegant and cheap, and do not
allow an as human-receivable control flow (imho), as a simple
jump can be.  Like my always quoted exampe that adds unnecessary
conditionals which evaluate over and over again for nothing

                if(defined($nl = $self->begin_line)){
                        $self->begin_line(undef);
                        $self->seen_endl(1);
                        $ogoditisanewperl = 1 #goto jumpin;
                }

                while($ogoditisanewperl || ($nl = readline $self->infh)){
                        if(!$ogoditisanewperl){
                                ++${$self->__lineno};
                                $self->seen_endl($nl =~ s/(.*?)\s+$/$1/)
                        }
                        $ogoditisanewperl = 0; #jumpin:

 |Of course, in those days it was setexit() etc :-)

  ENTRY(setexit, 0)
          movab   setsav,r0
          movq    r6,(r0)+
          movq    r8,(r0)+
          movq    r10,(r0)+
          movq    8(fp),(r0)+             # ap, fp
          movab   4(ap),(r0)+             # sp
          movl    16(fp),(r0)             # pc
          clrl    r0
          ret
  ENTRY(reset, 0)
          movl    4(ap),r0        # returned value
          movab   setsav,r1
          movq    (r1)+,r6
          movq    (r1)+,r8
          movq    (r1)+,r10
          movq    (r1)+,r12
          movl    (r1)+,sp
          jmp     *(r1)
  setsav: .space  10*4
          .text

Cheap it is not.  But maybe cheaper than calling a closure or
inner function with all the (repeated) stack setup and unwinding.

 |-- Dave
 --End of <alpine.BSF.2.21.9999.2303101657460.4881@aneurin.horsfall.org>

--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)

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Bakul Shah]

> On Mar 10, 2023, at 8:56 AM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> |Seriously, I also use setjmp()/longjmp() for a more elegant exit from a 
> 
> That is sheer unbelievable, really?  _So_ expensive!
> 
> |deeply-nested loop; "break N" to break out of "N" loops, anyone?  I 
> |haven't found that yet...

I suspect Dave means deeply nested function calls.

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Dave Horsfall]

On Fri, 10 Mar 2023, Steffen Nurpmeso wrote:

> |Seriously, I also use setjmp()/longjmp() for a more elegant exit from a
> 
> That is sheer unbelievable, really?  _So_ expensive!

How often would you call setjmp()/longjmp()?

-- Dave

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Sun, Mar 12, 2023, 2:47 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Fri, 10 Mar 2023, Steffen Nurpmeso wrote:
>
> > |Seriously, I also use setjmp()/longjmp() for a more elegant exit from a
> >
> > That is sheer unbelievable, really?  _So_ expensive!
>
> How often would you call setjmp()/longjmp()
>

Cheap enough for occasional error handling, way too expensive for a generic
exception handling system... processors with lots of registers were more of
a problem...

Warner

>

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

[Steffen Nurpmeso]

Warner Losh wrote in
 <CANCZdfqOZ3wrHktZGk3BrHV5ZdbkDyRPGxH61Mq87TVDQRQh7A@mail.gmail.com>:
 |On Sun, Mar 12, 2023, 2:47 PM Dave Horsfall <dave@horsfall.org> wrote:
 |> On Fri, 10 Mar 2023, Steffen Nurpmeso wrote:
 |>
 |>>|Seriously, I also use setjmp()/longjmp() for a more elegant exit from a
 |>>
 |>> That is sheer unbelievable, really?  _So_ expensive!
 |>
 |> How often would you call setjmp()/longjmp()

Only on a Sunday!

I never used these myself of free will.

(And never regulary at all until i took maintainership of a BSD
Mail clone, which is the examplary piece of software to show that
BSD signal handling and SA_RESTART are a terrible misconception,
especially as soon as the software gets larger. .. In my opinion.
Once it was able to run "24/6" i counted the number of system
calls necessary for signal block / release and installation
/ removal over a week, and i think the number was way in the six
digits.  System calls them all!  I should have taken the OpenBSD
variant instead, and simply take over what "was good", and it
would be much, much better by now.  They did the work and reduced
the very messy part to two exactly locatable system call points of
interest.  (I looked i guess 2014-<2017.)  A very bad decision.
But if i live long enough i will make it, and another one i would
really long for.)

 |Cheap enough for occasional error handling, way too expensive for a generic
 |exception handling system... processors with lots of registers were more of
 |a problem...

Even on a x86(-32) i have gnashed with my teeth.  And that with
a Cyrix from 1996 .. and not to think about i386 or even earlier
processors with so few memory and speed.
I remember _for sure_ looking at the jmpbuf structure by then, and
the assembler files (sheer magic by then) and x86 instructions.

"Some" jpeg library used jump buffers to signal errors.
(I got rid of most sources for things that will never come true,
but i do have libjpeg-turbo ball due to package dependencies, and
they also use that internally, but looking at it it seems to be
a different thing.)
That is maybe ok since image processing is maybe expensive enough
by itself to simply say they do not care about proper error paths
along the way but take a "dead-end exit".  (But it was i think not
like that with the jpeg i have in mind.)

--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)

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55thanniversary

[Dave Horsfall]

[ Followups to COFF, as this is rapidly becoming a Unix tutorial ]

On Sun, 12 Mar 2023, Warner Losh wrote:

> > How often would you call setjmp()/longjmp()?
> 
> Cheap enough for occasional error handling, way too expensive for a 
> generic exception handling system... processors with lots of registers 
> were more of a problem...

I've only ever used it when knee-deep in procedure calls, and I needed to 
parachute back to the main loop when things went pear-shaped[*]; failure 
was not an option :-)


On Sun, 12 Mar 2023, Steffen Nurpmeso wrote:

>  |> How often would you call setjmp()/longjmp()
> 
> Only on a Sunday!

Sometimes I did my best work outside of M-F 9-5 :-)

> I never used these myself of free will.
> 
> (And never regulary at all until i took maintainership of a BSD Mail 
> clone, which is the examplary piece of software to show that BSD signal 
> handling and SA_RESTART are a terrible misconception, especially as soon 
> as the software gets larger. .. In my opinion. Once it was able to run 
> "24/6" i counted the number of system calls necessary for signal block / 
> release and installation / removal over a week, and i think the number 
> was way in the six digits.  System calls them all!  I should have taken 
> the OpenBSD variant instead, and simply take over what "was good", and 
> it would be much, much better by now.  They did the work and reduced the 
> very messy part to two exactly locatable system call points of interest.  
> (I looked i guess 2014-<2017.)  A very bad decision. But if i live long 
> enough i will make it, and another one i would really long for.)

I've never liked the concept of signals, especially for IPC; it's akin to 
being hit over the head with a lump of 4x2.  Hardware interrupts were one 
thing, but it seemed to be a bit brutal in software.

And no, I don't have an elegant solution short of message-passing.

Heck, I still have nightmares about BSDi's "fdump" program using signals
to coordinate its various children, and completely screwing up my
backups as a result...

> Even on a x86(-32) i have gnashed with my teeth.  And that with
> a Cyrix from 1996 .. and not to think about i386 or even earlier
> processors with so few memory and speed.
> I remember _for sure_ looking at the jmpbuf structure by then, and
> the assembler files (sheer magic by then) and x86 instructions.

You can read X86 assembler?  I can only do that after a few stiff
drinks...  I did buy the book (in order to debug a floating bug defect
in the optimiser -- hey, let's optimise this instruction right out! -- and
I've never trusted optimisers since).

[*]
Cue the saying about it being impossible to design a foolproof system.

-- Dave, the iconoclast

[TUHS] Re: I can't drive 55: "GOTO considered harmful" 55thanniversary

[Steffen Nurpmeso]

Dave Horsfall wrote in
 <alpine.BSF.2.21.9999.2303131331350.67613@aneurin.horsfall.org>:
 |[ Followups to COFF, as this is rapidly becoming a Unix tutorial ]
 ..
 |On Sun, 12 Mar 2023, Steffen Nurpmeso wrote:
 ...
 |> Even on a x86(-32) i have gnashed with my teeth.  And that with
 ...
 |You can read X86 assembler?  I can only do that after a few stiff

Unfortunately i stopped my ambitions (nasm was non-portable but
fun).  I never stepped to ARM, i hate that, i read according Net
and FreeBSD commits with lots of interest.  Many years ago there
was a thrilling commit series for string and memory ops on NetBSD
that i sometimes still speak of ... Matt Thomas i think it was.
("Thrilling" it was for me; by then.)

 |drinks...  I did buy the book (in order to debug a floating bug defect
 |in the optimiser -- hey, let's optimise this instruction right out! -- and

But floating-point i run away.

 |I've never trusted optimisers since).
 |
 |[*]
 |Cue the saying about it being impossible to design a foolproof system.
 |
 |-- Dave, the iconoclast

"Dawn Of The Iconoclast"; Lisa Gerrard is also an Aussie and
nuclear she is, isn't she.  (Shown with unforgotten Klaus Schulze
at the Loreley -- since most of the UNIX beards are surely some
kind of long haired beauties this could even go to TUHS.)

Yeah, signals, no.  Problems anywhere.  But i have a
  command PKILL_TMUX "pkill -CONT tmux"
in my ~/.cwmrc (when Linux sends ^Z to the wrong for whatever
reason), and enough ptys to go to when ogg123 again gets an
interruption wrong and hangs deadly, only killable via -KILL.
I think setting a flag plus EINTR is a way, but ERESTART is not
handable if you sit on something blocking but have to act upon the
signal; message passing -- if you do have an event loop based
program then this is nice; then again i woke up with horrors for
the (first) Linux thread library (i have looked in) over twenty
years ago, and they used a worker and serialization via such as
a regular thing; also owed to Butenhof's POSIX thread design of
course, which is too "free" in my eyes (i'd rather have
a dedicated main thread plus workers); just like C++ exceptions (i
saw software which "throws char*").

 --End of <alpine.BSF.2.21.9999.2303131331350.67613@aneurin.horsfall.org>

--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)