From Newsgroup: comp.lang.c

On Thu, 12 Dec 2024 14:44:54 +0200, Michael S wrote:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson > wrote:

bart > writes:
[...]

My experience of multi-level break is that there are two main
use-cases:

* Used in the current loop only (not necessarily the innermost to
an observer). This is the most common

* Used to exit the outermost loop

So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

I would oppose a change to C that only applied to innermost and
outermost loops. For one thing, I'm not aware of any other language
that does this (except perhaps your unnamed one). For another,
it's easy enough to define a feature that handles any arbitrary
nesting levels, by applying names (labels) to loops.

The better solution is education.
Convince teachers in unis and colleges that goto is *not* considered
harmful for this particular use case. Convince them to teach that

goto is not harmful in every case, if the people that write it, indent
that goto significally and have clear in mind and in the text, what
that goto has to do

attempts to avoid goto [for this particular use case] are really
considered harmful. If you don't believe in authority of yourself then
ask for help from somebody famous that share this view. I would guess
that nearly all famous C programmers share it.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Fri, 20 Dec 2024 13:52:13 +0100
Rosario19 <Ros@invalid.invalid> wrote:

On Thu, 12 Dec 2024 14:44:54 +0200, Michael S wrote:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson > wrote:

bart > writes:
[...]

My experience of multi-level break is that there are two main
use-cases:

* Used in the current loop only (not necessarily the innermost
to an observer). This is the most common

* Used to exit the outermost loop

So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

I would oppose a change to C that only applied to innermost and
outermost loops. For one thing, I'm not aware of any other
language that does this (except perhaps your unnamed one). For
another, it's easy enough to define a feature that handles any
arbitrary nesting levels, by applying names (labels) to loops.

The better solution is education.
Convince teachers in unis and colleges that goto is *not* considered >harmful for this particular use case. Convince them to teach that

goto is not harmful in every case, if the people that write it, indent
that goto significally and have clear in mind and in the text, what
that goto has to do

I don't agree. Many sorts of goto are hard to understand for the reader
even when they are crystal clear to the writer [at the moment of
writing].
That applies to nearly all forward gotos into block and to nearly all
backward gotos. That is, there exists one sort of backward goto that I
find sufficiently understandable, but right now I am unable to
formalize its exact properties.
At large, Dijkstra is more right than wrong.

Of course, nothing of said above is relevant in context of gotos that
exit inner loops.










--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> writes:

On Fri, 20 Dec 2024 13:52:13 +0100
Rosario19 <Ros@invalid.invalid> wrote:

On Thu, 12 Dec 2024 14:44:54 +0200, Michael S wrote:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson > wrote:

bart > writes:
[...]

My experience of multi-level break is that there are two
main use-cases:

* Used in the current loop only (not necessarily the
innermost to an observer). This is the most common

* Used to exit the outermost loop

So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

I would oppose a change to C that only applied to innermost and
outermost loops. For one thing, I'm not aware of any other
language that does this (except perhaps your unnamed one). For
another, it's easy enough to define a feature that handles any
arbitrary nesting levels, by applying names (labels) to loops.

The better solution is education.
Convince teachers in unis and colleges that goto is *not*
considered harmful for this particular use case. Convince them
to teach that

I don't agree with this strategy. More explanation below.

goto is not harmful in every case, if the people that write it,
indent that goto significally and have clear in mind and in the
text, what that goto has to do

I don't agree. Many sorts of goto are hard to understand for the
reader even when they are crystal clear to the writer [at the
moment of writing].
That applies to nearly all forward gotos into block and to nearly
all backward gotos. That is, there exists one sort of backward
goto that I find sufficiently understandable, but right now I am
unable to formalize its exact properties.

Of course, nothing of said above is relevant in context of gotos
that exit inner loops.

In my view using goto should always be done on a case-by-case basis
and not under any general rule. More specifically, when first
writing a function it should be written without using goto (which is
always possible). If something about the code feels off, write it
another way, still without using goto. Continue re-writing in this
way as long as the results are dissatisfying, up to perhaps four or
five versions (in some cases I have done a lot more than that). In
many cases function bodies start off too large, and the code can be
simplified and clarified by breaking a function into several smaller sub-functions; doing that often removes any sense that goto is
needed.

After making multiple attempts, if none of the alternatives reaches
a suitable subjective quality assessment, then trying writing a
version with goto (or perhaps several versions, depending on other
factors). If the best using-goto version is judged better than the
best non-goto version, then use it; otherwise use the best non-goto
version.

I might add that I do end up using goto (rarely) in various unusual circumstances, and some of those uses are truly horrific. I am
content that they are appropriate because the non-goto versions
tried have all been worse along one or more axes.

At large, Dijkstra is more right than wrong.

In my reading Dijkstra's point is not that goto should be avoided
but that teaching goto should be avoided: student who learn to
write code using goto tend to produce tangled messes, at least more
than do those who are taught to use structured patterns of control
and not taught to use goto. Reportedly Dijkstra has said that he is
not dogmatic about avoiding the use of goto, but it's important also
to understand the original point: using goto should never be the
first line of defense, and education should reinforce that aphorism.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Tue, 24 Dec 2024 09:05:27 -0800, Tim Rentsch <> wrote:

Michael S <> writes:

On Fri, 20 Dec 2024 13:52:13 +0100
Rosario19 <Ros@invalid.invalid> wrote:

On Thu, 12 Dec 2024 14:44:54 +0200, Michael S wrote:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson > wrote:

bart > writes:
[...]

My experience of multi-level break is that there are two
main use-cases:

* Used in the current loop only (not necessarily the
innermost to an observer). This is the most common

* Used to exit the outermost loop

So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

I would oppose a change to C that only applied to innermost and
outermost loops. For one thing, I'm not aware of any other
language that does this (except perhaps your unnamed one). For
another, it's easy enough to define a feature that handles any
arbitrary nesting levels, by applying names (labels) to loops.

The better solution is education.
Convince teachers in unis and colleges that goto is *not*
considered harmful for this particular use case. Convince them
to teach that

I don't agree with this strategy. More explanation below.

goto is not harmful in every case, if the people that write it,
indent that goto significally and have clear in mind and in the
text, what that goto has to do

I don't agree. Many sorts of goto are hard to understand for the
reader even when they are crystal clear to the writer [at the
moment of writing].
That applies to nearly all forward gotos into block and to nearly
all backward gotos. That is, there exists one sort of backward
goto that I find sufficiently understandable, but right now I am
unable to formalize its exact properties.

Of course, nothing of said above is relevant in context of gotos
that exit inner loops.

In my view using goto should always be done on a case-by-case basis
and not under any general rule. More specifically, when first
writing a function it should be written without using goto (which is
always possible). If something about the code feels off, write it
another way, still without using goto. Continue re-writing in this
way as long as the results are dissatisfying, up to perhaps four or
five versions (in some cases I have done a lot more than that). In
many cases function bodies start off too large, and the code can be >simplified and clarified by breaking a function into several smaller >sub-functions; doing that often removes any sense that goto is
needed.

in my vew
goto it is needed because all that high level language is traslated in
the end, in easy istructions that use goto

one for see the error could be necessary see the assembly and follow
all the goto there are there...

but for me "if goto" could be ok even as one easy replacement of the
usual loop as "while" "for" etc

Buon Natale a tutti
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Rosario19 <Ros@invalid.invalid> writes:

On Tue, 24 Dec 2024 09:05:27 -0800, Tim Rentsch <> wrote:

In my view using goto should always be done on a case-by-case basis
and not under any general rule. More specifically, when first
writing a function it should be written without using goto (which is
always possible). If something about the code feels off, write it
another way, still without using goto. Continue re-writing in this
way as long as the results are dissatisfying, up to perhaps four or
five versions (in some cases I have done a lot more than that). In
many cases function bodies start off too large, and the code can be
simplified and clarified by breaking a function into several smaller
sub-functions; doing that often removes any sense that goto is
needed.

in my vew
goto it is needed because all that high level language is traslated in
the end, in easy istructions that use goto

Goto is never necessary. I have used at least three programming
languages that didn't have goto at all. And that's not counting
unusual languages like Prolog.
--- Synchronet 3.20a-Linux NewsLink 1.114