"GOTOphobia considered harmful (in C)" by Jorengarenar
https://blog.joren.ga/gotophobia-harmful

"gotophobia – fear of goto statement, usually caused by misunderstanding
and lack of context of stories from dark ages of programming.
Programmers with gotophobia tend to make their code less readable just
to avoid using goto."

"Everybody and their grandpa knows (the meme title of) Dijkstra's
Letters to the editor: go to statement considered harmful (submitted
under the title: A case against the goto statement), but most forget the
context of the 60s in which it was written, things we take for granted
were a novelty back then."

Lynn

On Thursday, 2 March 2023 at 01:00:26 UTC+2, Lynn McGuire wrote:
> "GOTOphobia considered harmful (in C)" by Jorengarenar
> https://blog.joren.ga/gotophobia-harmful
>
> "gotophobia – fear of goto statement, usually caused by misunderstanding
> and lack of context of stories from dark ages of programming.
> Programmers with gotophobia tend to make their code less readable just
> to avoid using goto."
>
> "Everybody and their grandpa knows (the meme title of) Dijkstra's
> Letters to the editor: go to statement considered harmful (submitted
> under the title: A case against the goto statement), but most forget the
> context of the 60s in which it was written, things we take for granted
> were a novelty back then."
>
A well used goto can sometimes help people to reason about code. Some
usages are idiomatic like cleanup and multi-level break/continue ... and
so should be taught to C students.

OTOH more loose branching can make compiler to statically analyse
it worse and so to warn incorrectly or to miss opportunity to optimise.

Tools help mainstream/average users the most. As programmers
use goto now more rarely the benchmarks and tests also contain
it less. So just avoiding it does not hurt, only avoiding at all costs
can be harmful.

Lynn McGuire:

> "GOTOphobia considered harmful (in C)" by Jorengarenar
> https://blog.joren.ga/gotophobia-harmful
>
> "gotophobia -- fear of goto statement, usually caused by
> misunderstanding and lack of context of stories from dark
> ages of programming. Programmers with gotophobia tend to
> make their code less readable just to avoid using goto."

I entirely agree with this statement. In fact, I use some of
the patterns from that article in my C# code. See also my
similar comments to Ned Batchelder's great article about
exceptions:

https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Am 02.03.2023 um 09:40 schrieb Anton Shepelev:

> -- () ascii ribbon campaign -- against html e-mail /\
> www.asciiribbon.org -- against proprietary attachments

With this website-design you'll gain no attention at all. ;-)

Bonita Montero:
> Anton Shepelev:
>
> > > -- () ascii ribbon campaign -- against html e-mail /
> > > www.asciiribbon.org -- against proprietary attachments
>
> With this website-design you'll gain no attention at all.
> ;-)

Unlike the Responsive Design, which Google viciously
promotes by favouring it in its seaches and which is the
negation of itself, being slow, bloated, and irresponsive,
asciiribbon.org is a good wesbiste: clean, fast, HTML,
adapts to the width of the browser window, uses normal fonts
viewable without smoothing, and requires very little
resources.

Why did you mangle my signature?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Am 02.03.2023 um 10:38 schrieb Anton Shepelev:

> Unlike the Responsive Design, which Google viciously
> promotes by favouring it in its seaches and which is the
> negation of itself, being slow, bloated, and irresponsive,
> asciiribbon.org is a good wesbiste: clean, fast, HTML,
> adapts to the width of the browser window, uses normal fonts
> viewable without smoothing, and requires very little
> resources.

I've got a computer from 2017 with to 27" QHD-monitors
and a 50/25 line and don't have any convenience-issues
with any webpage.

Bonita Montero:

> I've got a computer from 2017 with to 27" QHD-monitors and
> a 50/25 line and don't have any convenience-issues with
> any webpage.

I have a single 17-inch 5:4 display at work and a single
19-inch 4:3 one at home (which seems largish). The ergonomic
line length being about 70 characters, often I have to
shrink the browser window to make it narrower than my
display. Large (and especially widescreen) displays make me
stretch my neck. Also, I hate it if the pixels are two
small, so High-DPI is out of the question. My optimal raster
depth is about 90 ppi. Horisontally large displays spoil the
taste of the inexperienced, by encouraging long code lines.

If by "50/25 line" you refer to the standard text modes of
80x25 and 80x50 characters, then I sympathise with you,
although I can't imagine such a mode on so huge a display.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Öö Tiib <ootiib@hot.ee> writes:

> On Thursday, 2 March 2023 at 01:00:26 UTC+2, Lynn McGuire wrote:
>> "GOTOphobia considered harmful (in C)" by Jorengarenar
>> https://blog.joren.ga/gotophobia-harmful
>>
>> "gotophobia – fear of goto statement, usually caused by misunderstanding
>> and lack of context of stories from dark ages of programming.
>> Programmers with gotophobia tend to make their code less readable just
>> to avoid using goto."
>>
>> "Everybody and their grandpa knows (the meme title of) Dijkstra's
>> Letters to the editor: go to statement considered harmful (submitted
>> under the title: A case against the goto statement), but most forget the
>> context of the 60s in which it was written, things we take for granted
>> were a novelty back then."
>>
> A well used goto can sometimes help people to reason about code.

That's possible (since you say 'a' and that implies just one) but I've
not seen a case where what I call reasoning about code is easier with
any gotos.

It's common to think about gotos backwards -- that they solve a problem
at the point where one inserts one -- but the issue is that they create
problems at the point they jump to. To reason about code you need to
know the state of system at every point, and every jump to a label gives
another whole set of possible states that must be considered at the
target, and they are very unlikely to be closely related to the other
states one is already considering.

What usually goes by the term "a well used goto" is an attempt to
minimise this problem.

> Some
> usages are idiomatic like cleanup and multi-level break/continue ... and
> so should be taught to C students.

So that the copy that pattern in their own code or just so that they can
understand it when they see it? I think you mean the former as there is
not much to teach in the other case.

> OTOH more loose branching can make compiler to statically analyse
> it worse and so to warn incorrectly or to miss opportunity to optimise.
>
> Tools help mainstream/average users the most. As programmers
> use goto now more rarely the benchmarks and tests also contain
> it less. So just avoiding it does not hurt, only avoiding at all costs
> can be harmful.

Well that's one of those things that it true because of the phrasing --
nothing (in coding) should be avoided "at all costs"! The question is
what is the cost of avoiding gotos? In my experience it is usually a
benefit and not a cost at all.

--
Ben.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Lynn McGuire:
>
>> "GOTOphobia considered harmful (in C)" by Jorengarenar
>> https://blog.joren.ga/gotophobia-harmful
>>
>> "gotophobia -- fear of goto statement, usually caused by
>> misunderstanding and lack of context of stories from dark
>> ages of programming. Programmers with gotophobia tend to
>> make their code less readable just to avoid using goto."
>
>I entirely agree with this statement. In fact, I use some of
>the patterns from that article in my C# code. See also my
>similar comments to Ned Batchelder's great article about
>exceptions:
>
> https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

A fair amount of nonsense, cherry picking egregious examples of
one method and slighting the egregious examples of the other.

Scott Lurndal to Anton Shepelev:

> > https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239
>
> A fair amount of nonsense, cherry picking egregious
> examples of one method and slighting the egregious
> examples of the other.

That is your opinion. Where are your arguments? Which
examples do you think I cherry-picked and which I slighted?
Slighing implies unjustified rebuke, whereas I provided
arguments.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239
>>
>> A fair amount of nonsense, cherry picking egregious
>> examples of one method and slighting the egregious
>> examples of the other.
>
>That is your opinion. Where are your arguments? Which
>examples do you think I cherry-picked and which I slighted?
>Slighing implies unjustified rebuke, whereas I provided
>arguments.

Personally, I find both exceptions and status returns useful,
favoring the later because it is generally much easier to
attempt to recover from an issue closer to the issue. For example,
the 'open' system call returns a status code and the calling function
has all the appropriate information (file name, reason for failure)
to deal with the issue immediately, rather than defering to some
exception handler somewhere which may not have the context necessary
to handle the issue intelligently.

IME, most programmers who use exceptions simply terminate the application; the
applications (operating systems, hypervisors, large-scale simulation
tools) require more than simply crashing on exception.

Then there is inevitable run-time overhead cost to maintain the
ability to unwind the stack when handling exceptions, which in
at least one case (a CPU simulator) where I attempted to replace 'siglongjmp' with
standard C++ exceptions caused a 20% performance drop in the
application.

Scott Lurndal to Anton Shepelev:

> > Scott Lurndal to Anton Shepelev:
> >
> > > > https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239
> > >
> > > A fair amount of nonsense, cherry picking egregious
> > > examples of one method and slighting the egregious
> > > examples of the other.
> >
> > That is your opinion. Where are your arguments? Which
> > examples do you think I cherry-picked and which I
> > slighted? Slighing implies unjustified rebuke, whereas
> > I provided arguments.
>
> Personally, I find both exceptions and status returns
> useful, favoring the later because it is generally much
> easier to attempt to recover from an issue closer to the
> issue. For example, the 'open' system call returns a
> status code and the calling function has all the
> appropriate information (file name, reason for failure) to
> deal with the issue immediately, rather than defering to
> some exception handler somewhere which may not have the
> context necessary to handle the issue intelligently.

I agree. Did you get a different impression from my
comments above? Or, perhaps, you referred to Ned
Batchelder's blog post rather than to my comments?

> IME, most programmers who use exceptions simply terminate
> the application; the applications (operating systems,
> hypervisors, large-scale simulation tools) require more
> than simply crashing on exception.

In my experience, this is childish and stupid. Where I am
forced to use exceptions, I certainly use them in more
complex ways, including gathering information though several
stack levels, deinitialisation (e.g. transaction rollbakc),
and error recovery (e.g. reconnection and repeated DB
requests after deadlocks).

> Then there is inevitable run-time overhead cost to
> maintain the ability to unwind the stack when handling
> exceptions, which in at least one case (a CPU simulator)
> where I attempted to replace 'siglongjmp' with standard
> C++ exceptions caused a 20% performance drop in the
> application.

I thought the were implementations where the happy path
incurred zero overhead.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 02/03/2023 17:41, Anton Shepelev wrote:
> Scott Lurndal to Anton Shepelev:

>> Then there is inevitable run-time overhead cost to
>> maintain the ability to unwind the stack when handling
>> exceptions, which in at least one case (a CPU simulator)
>> where I attempted to replace 'siglongjmp' with standard
>> C++ exceptions caused a 20% performance drop in the
>> application.
>
> I thought the were implementations where the happy path
> incurred zero overhead.
>

The /aim/ is low overhead, but the practice is not always zero overhead.
(I suspect 20% performance overhead is quite unusual, however.)
Compilers are inevitably going to be more restricted when they are
required to be able to unwind the stack - it can limit reordering (since
throwing an exception becomes observable behaviour), or perhaps force
objects to be created on the stack in their entirety, whereas with
exceptions disabled the compiler might be able to put some or all of an
object in registers.

It is probably fair to say that exceptions are often more efficient (for
the non-exception path) compared to alternatives that do a similar
amount of work, but for some applications they are not close enough to
zero overhead to be suitable.

(In small systems embedded programming, it is standard practice to
compile with "-fno-exceptions".)

Am 02.03.2023 um 11:19 schrieb Anton Shepelev:

> I have a single 17-inch 5:4 display at work and a
> single 19-inch 4:3 one at home (which seems largish). ...

Use proper hardware.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > Scott Lurndal to Anton Shepelev:
>> >
>> > > > https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239
>> > >
>> > > A fair amount of nonsense, cherry picking egregious
>> > > examples of one method and slighting the egregious
>> > > examples of the other.
>> >
>> > That is your opinion. Where are your arguments? Which
>> > examples do you think I cherry-picked and which I
>> > slighted? Slighing implies unjustified rebuke, whereas
>> > I provided arguments.
>>
>> Personally, I find both exceptions and status returns
>> useful, favoring the later because it is generally much
>> easier to attempt to recover from an issue closer to the
>> issue. For example, the 'open' system call returns a
>> status code and the calling function has all the
>> appropriate information (file name, reason for failure) to
>> deal with the issue immediately, rather than defering to
>> some exception handler somewhere which may not have the
>> context necessary to handle the issue intelligently.
>
>I agree. Did you get a different impression from my
>comments above? Or, perhaps, you referred to Ned
>Batchelder's blog post rather than to my comments?

My apologies. The comment was directed at the blog post,
not your comments.

>
>> IME, most programmers who use exceptions simply terminate
>> the application; the applications (operating systems,
>> hypervisors, large-scale simulation tools) require more
>> than simply crashing on exception.
>
>In my experience, this is childish and stupid.

I don't disagree.

>Where I am
>forced to use exceptions, I certainly use them in more
>complex ways, including gathering information though several
>stack levels, deinitialisation (e.g. transaction rollbakc),
>and error recovery (e.g. reconnection and repeated DB
>requests after deadlocks).
>
>> Then there is inevitable run-time overhead cost to
>> maintain the ability to unwind the stack when handling
>> exceptions, which in at least one case (a CPU simulator)
>> where I attempted to replace 'siglongjmp' with standard
>> C++ exceptions caused a 20% performance drop in the
>> application.
>
>I thought the were implementations where the happy path
>incurred zero overhead.

I haven't seen that with gcc generated code, where there
are added calls to the crt code to handle stack unwinding
in functions even if the exception isn't thrown.

In the case above, it was a simple replacement of siglongjmp
with 'throw' that cost 20% in the execution speed of the
simulated processor.

On Thursday, 2 March 2023 at 15:27:38 UTC+2, Ben Bacarisse wrote:
> Öö Tiib <oot...@hot.ee> writes:
>
> > On Thursday, 2 March 2023 at 01:00:26 UTC+2, Lynn McGuire wrote:
> >> "GOTOphobia considered harmful (in C)" by Jorengarenar
> >> https://blog.joren.ga/gotophobia-harmful
> >>
> >> "gotophobia – fear of goto statement, usually caused by misunderstanding
> >> and lack of context of stories from dark ages of programming.
> >> Programmers with gotophobia tend to make their code less readable just
> >> to avoid using goto."
> >>
> >> "Everybody and their grandpa knows (the meme title of) Dijkstra's
> >> Letters to the editor: go to statement considered harmful (submitted
> >> under the title: A case against the goto statement), but most forget the
> >> context of the 60s in which it was written, things we take for granted
> >> were a novelty back then."
> >>
> > A well used goto can sometimes help people to reason about code.
> That's possible (since you say 'a' and that implies just one) but I've
> not seen a case where what I call reasoning about code is easier with
> any gotos.
>
Strange ... as in next sentence I brought three cases that are quite
idiomatic. Quantity is one or few as it is good idea to keep functions short.
> It's common to think about gotos backwards -- that they solve a problem
> at the point where one inserts one -- but the issue is that they create
> problems at the point they jump to. To reason about code you need to
> know the state of system at every point, and every jump to a label gives
> another whole set of possible states that must be considered at the
> target, and they are very unlikely to be closely related to the other
> states one is already considering.
>
> What usually goes by the term "a well used goto" is an attempt to
> minimise this problem.
>
I don't know what people think. I use goto where it makes my
intention more clear with well named label and also shortens the
code by reducing conditionals or removing duplicates.

> > Some
> > usages are idiomatic like cleanup and multi-level break/continue ... and
> > so should be taught to C students.
>
> So that the copy that pattern in their own code or just so that they can
> understand it when they see it? I think you mean the former as there is
> not much to teach in the other case.
>
Like with all idiomatic usages it is just how to handle certain situations.

> > OTOH more loose branching can make compiler to statically analyse
> > it worse and so to warn incorrectly or to miss opportunity to optimise.
> >
> > Tools help mainstream/average users the most. As programmers
> > use goto now more rarely the benchmarks and tests also contain
> > it less. So just avoiding it does not hurt, only avoiding at all costs
> > can be harmful.
>
> Well that's one of those things that it true because of the phrasing --
> nothing (in coding) should be avoided "at all costs"! The question is
> what is the cost of avoiding gotos? In my experience it is usually a
> benefit and not a cost at all.
>
Great. I however have seen plenty of misuses of other language
constructs for to get something done without goto. For example
do { /*code*/ } while(0); loop just to be able to use breaks as gotos
in that /*code*/.

Öö Tiib <ootiib@hot.ee> writes:

> On Thursday, 2 March 2023 at 15:27:38 UTC+2, Ben Bacarisse wrote:
>> Öö Tiib <oot...@hot.ee> writes:
>>
>> > On Thursday, 2 March 2023 at 01:00:26 UTC+2, Lynn McGuire wrote:
>> >> "GOTOphobia considered harmful (in C)" by Jorengarenar
>> >> https://blog.joren.ga/gotophobia-harmful
>> >>
>> >> "gotophobia – fear of goto statement, usually caused by misunderstanding
>> >> and lack of context of stories from dark ages of programming.
>> >> Programmers with gotophobia tend to make their code less readable just
>> >> to avoid using goto."
>> >>
>> >> "Everybody and their grandpa knows (the meme title of) Dijkstra's
>> >> Letters to the editor: go to statement considered harmful (submitted
>> >> under the title: A case against the goto statement), but most forget the
>> >> context of the 60s in which it was written, things we take for granted
>> >> were a novelty back then."
>> >>
>> > A well used goto can sometimes help people to reason about code.
>> That's possible (since you say 'a' and that implies just one) but I've
>> not seen a case where what I call reasoning about code is easier with
>> any gotos.
>>
> Strange ... as in next sentence I brought three cases that are quite
> idiomatic. Quantity is one or few as it is good idea to keep functions
> short.

I'm not sure what you think is strange.

>> It's common to think about gotos backwards -- that they solve a problem
>> at the point where one inserts one -- but the issue is that they create
>> problems at the point they jump to. To reason about code you need to
>> know the state of system at every point, and every jump to a label gives
>> another whole set of possible states that must be considered at the
>> target, and they are very unlikely to be closely related to the other
>> states one is already considering.
>>
>> What usually goes by the term "a well used goto" is an attempt to
>> minimise this problem.
>>
> I don't know what people think.

One advantage of teaching programming is that it's really helpful to ask
what your students are thinking. It helps to see where they are coming
from. Of course they may not e typical, but it gives an insight that is
often missing from other environments.

> I use goto where it makes my
> intention more clear with well named label and also shortens the
> code by reducing conditionals or removing duplicates.

I think everyone (nowadays) uses goto when it makes the intention clear.
But you raised the issue of reasoning about code (something I am very
keen on) so I made an observation about that, one that is often
overlooked: the purpose of the goto may be clear, but it complicates the
reasoning at the target.

>> > Some
>> > usages are idiomatic like cleanup and multi-level break/continue ... and
>> > so should be taught to C students.
>>
>> So that the copy that pattern in their own code or just so that they can
>> understand it when they see it? I think you mean the former as there is
>> not much to teach in the other case.
>>
> Like with all idiomatic usages it is just how to handle certain
> situations.

"It is just how to handle certain situations" does not address my
question. I know it /is/ done, but /should/ it be done? Should we
teach it just so that it's understood, or so that everyone keeps doing
it?

>> > OTOH more loose branching can make compiler to statically analyse
>> > it worse and so to warn incorrectly or to miss opportunity to optimise.
>> >
>> > Tools help mainstream/average users the most. As programmers
>> > use goto now more rarely the benchmarks and tests also contain
>> > it less. So just avoiding it does not hurt, only avoiding at all costs
>> > can be harmful.
>>
>> Well that's one of those things that it true because of the phrasing --
>> nothing (in coding) should be avoided "at all costs"! The question is
>> what is the cost of avoiding gotos? In my experience it is usually a
>> benefit and not a cost at all.
>>
> Great. I however have seen plenty of misuses of other language
> constructs for to get something done without goto. For example
> do { /*code*/ } while(0); loop just to be able to use breaks as gotos
> in that /*code*/.

breaks /are/ gotos[1] -- there's no avoiding that fact -- so they also
complicate the reasoning at the target. Writing convoluted code just to
disguise a goto as a break is bonkers, but it's more enlightening to
discuss best practice rather than worst!

[1] in C I don't count break in switch statements. There, it's /not/
writing a break that complicates things!

--
Ben.

Scott Lurndal to Anton Shepelev:

> > Scott Lurndal:
> >
> > > IME, most programmers who use exceptions simply
> > > terminate the application; the applications (operating
> > > systems, hypervisors, large-scale simulation tools)
> > > require more than simply crashing on exception.
> >
> > In my experience, this is childish and stupid.
>
> I don't disagree.

To explain -- throwing raw exceptions at the user rarely
helps him understand what went wrong, and where.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 02.03.2023 um 11:19 schrieb Anton Shepelev:
>
>> I have a single 17-inch 5:4 display at work and a
>> single 19-inch 4:3 one at home (which seems largish). ...
>
> Use proper hardware.

Most people do not share your definition of "proper".
Not everyone lives in a theater.

On Thursday, 2 March 2023 at 22:11:22 UTC+2, Ben Bacarisse wrote:
> Öö Tiib <oot...@hot.ee> writes:
>
> > On Thursday, 2 March 2023 at 15:27:38 UTC+2, Ben Bacarisse wrote:
> >> Öö Tiib <oot...@hot.ee> writes:
> >>
> >> >>
> >> > A well used goto can sometimes help people to reason about code.
> >> That's possible (since you say 'a' and that implies just one) but I've
> >> not seen a case where what I call reasoning about code is easier with
> >> any gotos.
> >>
> > Strange ... as in next sentence I brought three cases that are quite
> > idiomatic. Quantity is one or few as it is good idea to keep functions
> > short.
> I'm not sure what you think is strange.
>
I think it strange that you have never seen those idiomatic usages. I've
not seen better alternatives to some of those in C.

> > I use goto where it makes my
> > intention more clear with well named label and also shortens the
> > code by reducing conditionals or removing duplicates.
>
> I think everyone (nowadays) uses goto when it makes the intention clear.
> But you raised the issue of reasoning about code (something I am very
> keen on) so I made an observation about that, one that is often
> overlooked: the purpose of the goto may be clear, but it complicates the
> reasoning at the target.

It indeed can complicate reasoning for novice who is unfamiliar with
some idiom. Even MISRA C took less dogmatic stance towards goto about
ten years ago IIRC. So under some circumstances it is not that simple
to avoid.

Other programming languages have added language elements for those
circumstances like ... guard, defer, throw, repeat, scope, labeled break,
closures, coroutines, continuations and so on.
But more is often not better as we have experienced. Each of those
needs to be taught. Area of potential usage is dim, can overlap with other
element, performance costs can differ. So it is no way simpler to teach nor
to learn.

> >> > Some
> >> > usages are idiomatic like cleanup and multi-level break/continue ... and
> >> > so should be taught to C students.
> >>
> >> So that the copy that pattern in their own code or just so that they can
> >> understand it when they see it? I think you mean the former as there is
> >> not much to teach in the other case.
> >>
> > Like with all idiomatic usages it is just how to handle certain
> > situations.
>
> "It is just how to handle certain situations" does not address my
> question. I know it /is/ done, but /should/ it be done? Should we
> teach it just so that it's understood, or so that everyone keeps doing
> it?

My bad. I think both should be done. The problems where for example
multi-level break or continue are handy are typically interesting on their
own. Or the other example of proper handling of stopping, canceling or
retrying where multiple different resources may need to be released
(but language does not have exceptions or RAII) is useful skill.

> >> Well that's one of those things that it true because of the phrasing --
> >> nothing (in coding) should be avoided "at all costs"! The question is
> >> what is the cost of avoiding gotos? In my experience it is usually a
> >> benefit and not a cost at all.
> >>
> > Great. I however have seen plenty of misuses of other language
> > constructs for to get something done without goto. For example
> > do { /*code*/ } while(0); loop just to be able to use breaks as gotos
> > in that /*code*/.
>
> breaks /are/ gotos[1] -- there's no avoiding that fact -- so they also
> complicate the reasoning at the target. Writing convoluted code just to
> disguise a goto as a break is bonkers, but it's more enlightening to
> discuss best practice rather than worst!
>
"Those are gotos" can be said about early returns and exceptions
as well. But saying so presumes that goto is a bad thing.
I do not see it as bad thing ... just bit too generic. About like pointer
is bit too generic. There are no much else to do but to break the
loop when it is discovered that loop does not need to continue
looping (or even may not do so for safely) . So if there are no
break (nor early returns or exceptions) then we have goto.

Öö Tiib <ootiib@hot.ee> writes:

> On Thursday, 2 March 2023 at 22:11:22 UTC+2, Ben Bacarisse wrote:
>> Öö Tiib <oot...@hot.ee> writes:
>>
>> > On Thursday, 2 March 2023 at 15:27:38 UTC+2, Ben Bacarisse wrote:
>> >> Öö Tiib <oot...@hot.ee> writes:
>> >>
>> >> >>
>> >> > A well used goto can sometimes help people to reason about code.
>> >> That's possible (since you say 'a' and that implies just one) but I've
>> >> not seen a case where what I call reasoning about code is easier with
>> >> any gotos.
>> >>
>> > Strange ... as in next sentence I brought three cases that are quite
>> > idiomatic. Quantity is one or few as it is good idea to keep functions
>> > short.
>> I'm not sure what you think is strange.
>>
> I think it strange that you have never seen those idiomatic usages.

I don't know how you came to that conclusion. I've been using C for over
30 years, so of course I am aware of them. I even remember a time
before they had not yet become idiomatic!

What I was saying is that I've not seen an example that makes reasoning
about the code easier. I've seen cases where I don't think the goto
makes reasoning any harder, but not one where it actually helps to
reason about the code.

> I've
> not seen better alternatives to some of those in C.

That's the trouble when something becomes idiomatic -- the alternatives
become rare.

>> > I use goto where it makes my
>> > intention more clear with well named label and also shortens the
>> > code by reducing conditionals or removing duplicates.
>>
>> I think everyone (nowadays) uses goto when it makes the intention clear.
>> But you raised the issue of reasoning about code (something I am very
>> keen on) so I made an observation about that, one that is often
>> overlooked: the purpose of the goto may be clear, but it complicates the
>> reasoning at the target.
>
> It indeed can complicate reasoning for novice who is unfamiliar with
> some idiom.

You think I am a novice (or at least think like one) when it comes to
reasoning about code?

> Even MISRA C took less dogmatic stance towards goto about
> ten years ago IIRC. So under some circumstances it is not that simple
> to avoid.
>
> Other programming languages have added language elements for those
> circumstances like ... guard, defer, throw, repeat, scope, labeled break,
> closures, coroutines, continuations and so on.
> But more is often not better as we have experienced. Each of those
> needs to be taught. Area of potential usage is dim, can overlap with other
> element, performance costs can differ. So it is no way simpler to teach nor
> to learn.

I don't think we can get into that huge family of constructs. Let's
stick to talking about what C has.

>> >> > Some
>> >> > usages are idiomatic like cleanup and multi-level break/continue ... and
>> >> > so should be taught to C students.
>> >>
>> >> So that the copy that pattern in their own code or just so that they can
>> >> understand it when they see it? I think you mean the former as there is
>> >> not much to teach in the other case.
>> >>
>> > Like with all idiomatic usages it is just how to handle certain
>> > situations.
>>
>> "It is just how to handle certain situations" does not address my
>> question. I know it /is/ done, but /should/ it be done? Should we
>> teach it just so that it's understood, or so that everyone keeps doing
>> it?
>
> My bad. I think both should be done.

OK, thanks. I disagree, and I am happy to say more if you think it
might be useful in some way.

> The problems where for example
> multi-level break or continue are handy are typically interesting on their
> own. Or the other example of proper handling of stopping, canceling or
> retrying where multiple different resources may need to be released
> (but language does not have exceptions or RAII) is useful skill.

Yes, it is useful to know how to handle these cases. I rarely think
that goto is the best option, though I am not entirely opposed to their
use.

>> >> Well that's one of those things that it true because of the phrasing --
>> >> nothing (in coding) should be avoided "at all costs"! The question is
>> >> what is the cost of avoiding gotos? In my experience it is usually a
>> >> benefit and not a cost at all.
>> >>
>> > Great. I however have seen plenty of misuses of other language
>> > constructs for to get something done without goto. For example
>> > do { /*code*/ } while(0); loop just to be able to use breaks as gotos
>> > in that /*code*/.
>>
>> breaks /are/ gotos[1] -- there's no avoiding that fact -- so they also
>> complicate the reasoning at the target. Writing convoluted code just to
>> disguise a goto as a break is bonkers, but it's more enlightening to
>> discuss best practice rather than worst!
>>
> "Those are gotos" can be said about early returns and exceptions
> as well.

Such a case could be made for early returns, I agree. While some are
just an if with an implied else, others can indeed do more damage to the
reasoning.

C does not have exceptions (thank gooness!) which are a whole other can
of worms.

> But saying so presumes that goto is a bad thing.

I don't saying that they are gotos presumes that gotos are bad. break
and continue can also complicate the reasoning at the target, but I am
not an absolutist about the matter.

Also, I don't want to get into an argument about classification. If you
don't think of them as gotos with an implicit label, then that's fine.
Let's leave them to one side.

> I do not see it as bad thing ... just bit too generic. About like pointer
> is bit too generic. There are no much else to do but to break the
> loop when it is discovered that loop does not need to continue
> looping (or even may not do so for safely) . So if there are no
> break (nor early returns or exceptions) then we have goto.

That's an interesting turn of phrase. I think the style of programming
where one "discovers" that a loop needs to be stopped might be more of a
problem that the coding style that results from it.

--
Ben.

Ben Bacarisse:

> I've seen cases where I don't think the goto makes
> reasoning any harder, but not one where it actually helps
> to reason about the code.

Nested `if' statements express control flow as a binary
tree, but very frequently control flow is, pardon me, a
unary tree, or a stack:

INIT 1
INIT 2
INIT 3
....
CLEAN 3
CLEAN 2
CLEAN 1

It is linear in the sense that it is expressible as a
sequence of INIT-DEINIT pairs:

INIT 1 -- DEINIT 1
INIT 2 -- DEINIT 2
INIT 3 -- DEINIT 3

Expressing it with nested `if' statements is therefore
redundant, and this redundancy causes it to be perceived as
ugly, cumbersome, and unreadable:

IF INIT 1
IF INIT 2
IF INIT 3
DEINIT 3
DEINIT 2
DEINIT 1

so that adding another INIT-DEINIT pair requires another
nesting level, which I think is both structurally and
aesthetically poor, because elegant code grows vertically
rather than horisontally. `goto' statements can express
this control flow in a more structural manner:

IF NOT INIT 1 THEN GOTO E_1
IF NOT INIT 2 THEN GOTO E_2
IF NOT INIT 3 THEN GOTO E_3

DEINIT 3
E_3: DEINIT 2
E_2: DEINIT 1
E_1: NOP

Compared to structured control flow, `goto' seem indeed to
help reason about this code, and at least they do not thwart
reasoning as strongly.

How do you code linear sequences of operations where the
only non-linearity is due to the need to handle errors
and/or release resources?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Am 03.03.2023 um 11:45 schrieb Po Lu:

> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> Am 02.03.2023 um 11:19 schrieb Anton Shepelev:

>>> I have a single 17-inch 5:4 display at work and a
>>> single 19-inch 4:3 one at home (which seems largish). ...

>> Use proper hardware.

> Most people do not share your definition of "proper".
> ...

Most people would agree that the above hardware mentionend by Anton
isn't proper hardware.

On Friday, 3 March 2023 at 17:28:17 UTC+2, Ben Bacarisse wrote:
> Öö Tiib <oot...@hot.ee> writes:
>
> > On Thursday, 2 March 2023 at 22:11:22 UTC+2, Ben Bacarisse wrote:
> >> Öö Tiib <oot...@hot.ee> writes:
> >>
> >> > On Thursday, 2 March 2023 at 15:27:38 UTC+2, Ben Bacarisse wrote:
> >> >> Öö Tiib <oot...@hot.ee> writes:
> >> >>
> >> >> >>
> >> >> > A well used goto can sometimes help people to reason about code.
> >> >> That's possible (since you say 'a' and that implies just one) but I've
> >> >> not seen a case where what I call reasoning about code is easier with
> >> >> any gotos.
> >> >>
> >> > Strange ... as in next sentence I brought three cases that are quite
> >> > idiomatic. Quantity is one or few as it is good idea to keep functions
> >> > short.
> >> I'm not sure what you think is strange.
> >>
> > I think it strange that you have never seen those idiomatic usages.
>
> I don't know how you came to that conclusion. I've been using C for over
> 30 years, so of course I am aware of them. I even remember a time
> before they had not yet become idiomatic!
>
> What I was saying is that I've not seen an example that makes reasoning
> about the code easier. I've seen cases where I don't think the goto
> makes reasoning any harder, but not one where it actually helps to
> reason about the code.
>
OK maybe it is about "easy". I meant that when I see familiar patterns then
those make it easier for me to understand and reason about the situation.
With every feature it can be both ways, where it is expected and fits to
pattern where it seems odd. If it seems odd then on closer inspection
there is often some logic error, some missing check, inefficiency, resource
leak or unneeded repetition. Odd usage of goto can stand out as can lack
of it.
>
> > I've
> > not seen better alternatives to some of those in C.
> That's the trouble when something becomes idiomatic -- the alternatives
> become rare.
> >> > I use goto where it makes my
> >> > intention more clear with well named label and also shortens the
> >> > code by reducing conditionals or removing duplicates.
> >>
> >> I think everyone (nowadays) uses goto when it makes the intention clear.
> >> But you raised the issue of reasoning about code (something I am very
> >> keen on) so I made an observation about that, one that is often
> >> overlooked: the purpose of the goto may be clear, but it complicates the
> >> reasoning at the target.
> >
> > It indeed can complicate reasoning for novice who is unfamiliar with
> > some idiom.
>
> You think I am a novice (or at least think like one) when it comes to
> reasoning about code?
>
No. Like I said ... I know that I don't know how other people think. So I am
just proposing what can complicate reasoning. About 35 years ago someone
who some years later became main architect of software in a bank told me
that he hates for loops ... that for him it is easier to reason about ifs and
gotos. I was as puzzled as I'm now.

> >> >> > Some
> >> >> > usages are idiomatic like cleanup and multi-level break/continue .... and
> >> >> > so should be taught to C students.
> >> >>
> >> >> So that the copy that pattern in their own code or just so that they can
> >> >> understand it when they see it? I think you mean the former as there is
> >> >> not much to teach in the other case.
> >> >>
> >> > Like with all idiomatic usages it is just how to handle certain
> >> > situations.
> >>
> >> "It is just how to handle certain situations" does not address my
> >> question. I know it /is/ done, but /should/ it be done? Should we
> >> teach it just so that it's understood, or so that everyone keeps doing
> >> it?
> >
> > My bad. I think both should be done.
>
> OK, thanks. I disagree, and I am happy to say more if you think it
> might be useful in some way.
>
Yes it can be useful in some way.

> > The problems where for example
> > multi-level break or continue are handy are typically interesting on their
> > own. Or the other example of proper handling of stopping, canceling or
> > retrying where multiple different resources may need to be released
> > (but language does not have exceptions or RAII) is useful skill.
>
> Yes, it is useful to know how to handle these cases. I rarely think
> that goto is the best option, though I am not entirely opposed to their
> use.
>
I do not mean that goto is very commonly needed. For example nested
loops themselves do not scale and so should be avoided where possible.

> >> >> Well that's one of those things that it true because of the phrasing --
> >> >> nothing (in coding) should be avoided "at all costs"! The question is
> >> >> what is the cost of avoiding gotos? In my experience it is usually a
> >> >> benefit and not a cost at all.
> >> >>
> >> > Great. I however have seen plenty of misuses of other language
> >> > constructs for to get something done without goto. For example
> >> > do { /*code*/ } while(0); loop just to be able to use breaks as gotos
> >> > in that /*code*/.
> >>
> >> breaks /are/ gotos[1] -- there's no avoiding that fact -- so they also
> >> complicate the reasoning at the target. Writing convoluted code just to
> >> disguise a goto as a break is bonkers, but it's more enlightening to
> >> discuss best practice rather than worst!
> >>
> > "Those are gotos" can be said about early returns and exceptions
> > as well.
> Such a case could be made for early returns, I agree. While some are
> just an if with an implied else, others can indeed do more damage to the
> reasoning.
>
> C does not have exceptions (thank gooness!) which are a whole other can
> of worms.
>
Yes, exceptions without RAII (like in Java) can make it quite inconvenient
to manage important resources. As C has to manage all resources explicitly
it would be even more inconvenient feature.

> > But saying so presumes that goto is a bad thing.
> I don't saying that they are gotos presumes that gotos are bad. break
> and continue can also complicate the reasoning at the target, but I am
> not an absolutist about the matter.
>
> Also, I don't want to get into an argument about classification. If you
> don't think of them as gotos with an implicit label, then that's fine.
> Let's leave them to one side.
>
OK

> > I do not see it as bad thing ... just bit too generic. About like pointer
> > is bit too generic. There are no much else to do but to break the
> > loop when it is discovered that loop does not need to continue
> > looping (or even may not do so for safely) . So if there are no
> > break (nor early returns or exceptions) then we have goto.
>
> That's an interesting turn of phrase. I think the style of programming
> where one "discovers" that a loop needs to be stopped might be more of a
> problem that the coding style that results from it.
>
Mature software code base is usually such. About 80% of code lines
deal with various corner/edge cases and situations. Situation is
often impossible or expensive to predict before being in it. And then
it needs to deal with it cancel or undo what was done clean up and
forward the information about issue up stack.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Ben Bacarisse:
>
>> I've seen cases where I don't think the goto makes
>> reasoning any harder, but not one where it actually helps
>> to reason about the code.
>
> Nested `if' statements express control flow as a binary
> tree, but very frequently control flow is, pardon me, a
> unary tree, or a stack:
>
> INIT 1
> INIT 2
> INIT 3
> ....
> CLEAN 3
> CLEAN 2
> CLEAN 1
>
> It is linear in the sense that it is expressible as a
> sequence of INIT-DEINIT pairs:
>
> INIT 1 -- DEINIT 1
> INIT 2 -- DEINIT 2
> INIT 3 -- DEINIT 3
>
> Expressing it with nested `if' statements is therefore
> redundant, and this redundancy causes it to be perceived as
> ugly, cumbersome, and unreadable:

I don't perceive it that way. The nested blocks represent, both
visually and logically, the nested "stack" of actions.

But the perception is not really the point. I was talking about
reasoning about the code. I know how to reason about ifs, so when I
see:

FILE *in = fopen("input", "r");
if (in) {
FILE *out = fopen("output), "w");
if (out) {
char *buffer = malloc(1000);
if (buffer) {
// off we go!
free(buffer);
}
fclose(out);
}
fclose(in);
}

I know the fcloses are never performed on null file pointers (and if it
were more idiomatic in C, I'd put consts in there to have the compiler
check that 'in' and 'out' are not changed).

> IF INIT 1
> IF INIT 2
> IF INIT 3
> DEINIT 3
> DEINIT 2
> DEINIT 1
>
> so that adding another INIT-DEINIT pair requires another
> nesting level, which I think is both structurally and
> aesthetically poor, because elegant code grows vertically
> rather than horisontally.

You can make a case for the aesthetics (though I would probably
disagree) but it's not structurally poor to use the simplest and best
known structured programming construct.

But your adding another level brings up a very important point. When
you find that adding more nested constructs gets ugly, it's time to
think about a helper function. C is not the best assistant in this
regard (I have to write a top-level function and I can't easily return
multiple values) but I would still choose that option.

> `goto' statements can express
> this control flow in a more structural manner:
>
> IF NOT INIT 1 THEN GOTO E_1
> IF NOT INIT 2 THEN GOTO E_2
> IF NOT INIT 3 THEN GOTO E_3
>
> DEINIT 3
> E_3: DEINIT 2
> E_2: DEINIT 1
> E_1: NOP

This is simply not what I call structured. I think you object to
nesting even when it shows how the code is actually nested. The
structured version shows the structure!

When the actions involved are more complex than the text "INIT n" and
"DEINIT n" even the simply visual pattern matching starts to go wrong
with the goto version. Maybe you stick with numbers, but most people
don't and I have to check the label and goto ordering. And because this
pattern includes not extra blocks, my logical conditions (we are talking
about reasoning) has to include more variables.

> Compared to structured control flow, `goto' seem indeed to
> help reason about this code, and at least they do not thwart
> reasoning as strongly.

How does it help the reasoning? As far as I can see, I have more things
to check and more state to be aware of at every label.

> How do you code linear sequences of operations where the
> only non-linearity is due to the need to handle errors
> and/or release resources?

I use ifs and helper functions.

I understand that there is a lot of personal taste involved in the
broader topic, but when it comes to just the formal reasoning, I think
there is much less subjectivity.

--
Ben.