* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
@ 2023-03-10 11:37 Noel Chiappa
2023-03-10 11:51 ` [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Ralph Corderoy
2023-03-10 15:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Dan Cross
0 siblings, 2 replies; 75+ messages in thread
From: Noel Chiappa @ 2023-03-10 11:37 UTC (permalink / raw)
To: imp, segaloco; +Cc: tuhs
> From: Warner Losh
> In C I use it all the time to do goto err for common error recovery
> because C doesn't have anything better.
That's because C doesn't have 'conditions'. (Apparently, from the following
posts, most people here are unfamiliar with them. Too bad, they are a great
idea. OK summary here:
http://gunkies.org/wiki/Condition_handler
for those who are unfamiliar with the idea.)
I was at one point writing a compiler using a recursive descent parser, and
decided the code would be a lot simpler/cleaner if I had them. (If, for
example, one discovers discovers an un-expected 'end of file', there can be
an extremely large number of procedure invocations in between where that is
discovered, and where it is desirable to handle it. So every possible
intervening procedure would have to have an 'unexpected EOF' return value,
one would have to write code in every possible intervening procedure to
_handle_ an 'unexpected EOF' return value, etc.)'
(Yes, I could have used setjmp/longjmp; those are effectively a limited
version of condition handlers.)
Since C has a stack, it was relatively easy to implement, without any compiler
support: on() became a macro for 'if _on("condition_name")'; _on() was a
partially-assembler procedure which i) stacked the handler (I forget where I
put it; I may have created a special 'condition stack', to avoid too many
changes to the main C stack), and ii) patched the calling procedure's return
point to jump to some code that unstacked the handler, and iii) returned
'false'. If the condition occurred, a return from _on() was simulated,
returning 'true', etc.
So the code had things like:
on ("unexpected EOF") {
code to deal with it
}
With no compiler support, it added a tiny bit of overhead
(stacking/unstacking conditions), but not too bad.
John Wroclawski and someone implemented a very similar thing
entirely in C; IIRC it was built on top of setjmp/longjmp. I don't
recall how it dealt with un-stacking handlers on exit (which mine
did silently).
Noel
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-10 11:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
@ 2023-03-10 11:51 ` Ralph Corderoy
2023-03-10 15:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Dan Cross
1 sibling, 0 replies; 75+ messages in thread
From: Ralph Corderoy @ 2023-03-10 11:51 UTC (permalink / raw)
To: tuhs
Hi Noel,
> > In C I use it all the time to do goto err for common error recovery
> > because C doesn't have anything better.
>
> That's because C doesn't have 'conditions'. (Apparently, from the following
> posts, most people here are unfamiliar with them. Too bad, they are a great
> idea. OK summary here:
>
> http://gunkies.org/wiki/Condition_handler
I wasn't familiar with the term ‘condition handler’. That page starts
‘A condition handler (sometimes exception handler) refers to a
mechanism in some programming languages which allows the programmer
to provide code to handle the occurrence of a exception or condition
(terminology varies, but the substance does not).’
Oh, exceptions. I know what they are and if you say above that most
people are unfamiliar with them due to their use of goto then that's
probably wrong.
There are good reasons languages like Go chose not to include them.
https://go.dev/doc/faq#exceptions
--
Cheers, Ralph.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 11:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 11:51 ` [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Ralph Corderoy
@ 2023-03-10 15:54 ` Dan Cross
2023-03-12 7:39 ` Anthony Martin
1 sibling, 1 reply; 75+ messages in thread
From: Dan Cross @ 2023-03-10 15:54 UTC (permalink / raw)
To: Noel Chiappa; +Cc: segaloco, tuhs
On Fri, Mar 10, 2023 at 6:37 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>
> > From: Warner Losh
>
> > In C I use it all the time to do goto err for common error recovery
> > because C doesn't have anything better.
>
> That's because C doesn't have 'conditions'. (Apparently, from the following
> posts, most people here are unfamiliar with them. Too bad, they are a great
> idea. OK summary here:
>
> http://gunkies.org/wiki/Condition_handler
>
> for those who are unfamiliar with the idea.)
I don't know if I'd say they're a great idea.
The problem with exceptions (nee conditions, though I most often
associate the term "condition" with Lisp, and in particular Common
Lisp's implementation has a rather different flavor in the ability to
restart execution _at the point where the condition was raised_, even
if the handler is conceptually much higher up in the call stack) is
that they introduce non-linear control flow, which can be very
difficult to reason about. This is especially challenging in code that
may allocate resources and must manually deallocate them (such as C);
without some notion of RAII or finalizers for arbitrary objects. It's
really easy to introduce leaks in code with exceptions, and while
often this is for memory, where you're ok if you're in a garbage
collected language, you're gonna have a bad day when it's for
something like file descriptors (which are much scarcer than memory).
Unless pretty much everything is behind a stack guard, or whatever the
moral equivalent in your language is, you're constrained to handling
the errors at many places in the call stack, in which case, why
bother?
But the point about error handling and the use of `goto` in C in lieu
of something better is well taken, and conditions are _a_ reasonable
mechanism for dealing with the issue. I'd argue that a `Result` monad
and some short-circuiting sugar used in conjunction with RAII is
another that is better. For example in Rust, the result type interacts
with the `?` operator so that, if a call returns a `Result<T, E>`, the
T will be unwrapped if the result is Ok(T), otherwise, the code will
return `Err(E)`. So one can write code that has the brevity of
exceptions without introducing the control-flow weirdness:
fn make_request(host: &str) -> std::io::Result<()> {
let req = "hi\r\n".as_bytes();
std::net::TcpStream::connect(host)?.write(req)?;
Ok(())
}
(Note that the TCP stream will be "dropped" after the call to `write`,
and the drop impl on the TcpStream type will close the socket.)
Combined with pattern matching on the error type, this is quite expressive.
> I was at one point writing a compiler using a recursive descent parser, and
> decided the code would be a lot simpler/cleaner if I had them. (If, for
> example, one discovers discovers an un-expected 'end of file', there can be
> an extremely large number of procedure invocations in between where that is
> discovered, and where it is desirable to handle it. So every possible
> intervening procedure would have to have an 'unexpected EOF' return value,
> one would have to write code in every possible intervening procedure to
> _handle_ an 'unexpected EOF' return value, etc.)'
>
> (Yes, I could have used setjmp/longjmp; those are effectively a limited
> version of condition handlers.)
>
> Since C has a stack, it was relatively easy to implement, without any compiler
> support: on() became a macro for 'if _on("condition_name")'; _on() was a
> partially-assembler procedure which i) stacked the handler (I forget where I
> put it; I may have created a special 'condition stack', to avoid too many
> changes to the main C stack), and ii) patched the calling procedure's return
> point to jump to some code that unstacked the handler, and iii) returned
> 'false'. If the condition occurred, a return from _on() was simulated,
> returning 'true', etc.
>
> So the code had things like:
>
> on ("unexpected EOF") {
> code to deal with it
> }
>
> With no compiler support, it added a tiny bit of overhead
> (stacking/unstacking conditions), but not too bad.
>
> John Wroclawski and someone implemented a very similar thing
> entirely in C; IIRC it was built on top of setjmp/longjmp. I don't
> recall how it dealt with un-stacking handlers on exit (which mine
> did silently).
The plan9 kernel has something remarkably similar; there is a
pre-process error stack containing the local equivalent of a bunch of
`jmp_buf`'s. One could write, `if (waserror()) { /* handle cleanup */
}` where, `waserror` would push a jmp_buf onto the stack a la the
`setjmp` equivalent. Code later on could call `error(Ewhatever)` and
that would cache the error somewhere in the proc struct and invoke the
`longjmp` equivalent to jump back to the label at the top of the
stack, where `waserror()` would now return 1. Things would have to
manually `poperror()`, to pop the stack. I'm told that the plan9 C
compilers were callee-save in part to keep these state labels svelte.
This got pulled into the Akaros kernel at one point, and for a while,
we had someone working with us who was pretty prominent in the Linux
community. What was interesting was that he was so used to the `goto
err;` convention from that world that he just could not wrap his head
around how the `waserror()` stuff worked; at one point there was a
sequence like,
char *foo;
if (waserror()) {
free(foo);
return -1;
}
foo = malloc(len);
something();
free(foo);
return 0;
...and the guy just couldn't get how the code inside of the
`waserror()` wasn't trashing the system, since obviously the malloc
was done after `waserror()`, and so the pointer was meaningless at
that point. It took quite a while to explain what was going on.
Btw: I was once told by a reliable authority that the Go developers
considered implementing exceptions, but decided against it because of
the cognitive load it imposes.
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 15:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Dan Cross
@ 2023-03-12 7:39 ` Anthony Martin
2023-03-12 11:40 ` Dan Cross
0 siblings, 1 reply; 75+ messages in thread
From: Anthony Martin @ 2023-03-12 7:39 UTC (permalink / raw)
To: Dan Cross; +Cc: tuhs
Dan Cross <crossd@gmail.com> once said:
> I'm told that the plan9 C compilers were callee-save in part to keep
> these state labels svelte.
The Plan 9 compilers are caller-save. That means the labels only have
to contain pc and sp. Waserror works well except for one small issue
involving whether or not the compiler decides to store a value to a
non-volatile, non-pointer variable when the value would not be used
after a function call. As in:
int a;
a = 1;
if(waserror()){ /* ... */ }
a = 2;
a = foo(a);
The waserror branch may see a == 1 if foo errors.
Ken's compilers are great, though. They don't engage in antisocial
optimizations based on dubious notions of undefined behavior. I'd
prefer my compiler to not elide explicit null checks or loads and
stores from a pointer.
Cheers,
Anthony
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-12 7:39 ` Anthony Martin
@ 2023-03-12 11:40 ` Dan Cross
2023-03-12 16:40 ` Paul Winalski
2023-03-13 3:25 ` John Cowan
0 siblings, 2 replies; 75+ messages in thread
From: Dan Cross @ 2023-03-12 11:40 UTC (permalink / raw)
To: Anthony Martin; +Cc: TUHS
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Sun, Mar 12, 2023, 3:39 AM Anthony Martin <ality@pbrane.org> wrote:
> Dan Cross <crossd@gmail.com> once said:
> > I'm told that the plan9 C compilers were callee-save in part to keep
> > these state labels svelte.
>
> The Plan 9 compilers are caller-save. That means the labels only have
> to contain pc and sp.
Indeed. I typo-ed but meant caller-save; it wouldn't be very svelte if it
were the other way around. ;-)
Waserror works well except for one small issue
> involving whether or not the compiler decides to store a value to a
> non-volatile, non-pointer variable when the value would not be used
> after a function call. As in:
>
> int a;
> a = 1;
> if(waserror()){ /* ... */ }
> a = 2;
> a = foo(a);
>
> The waserror branch may see a == 1 if foo errors.
>
> Ken's compilers are great, though. They don't engage in antisocial
> optimizations based on dubious notions of undefined behavior. I'd
> prefer my compiler to not elide explicit null checks or loads and
> stores from a pointer.
It is certainly a shame that modern compiler writers have become
essentially hostile to programmers in their pursuit of ever more aggressive
optimizations based on rigid readings of the standard, common sense be
damned.
As for the plan9 C _language_, in the late 80s, it was arguably an
improvement over what ANSI put out. Nowadays, however, I think the inverse
is true. *Shrug*
- Dan C.
[-- Attachment #2: Type: text/html, Size: 2327 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-12 11:40 ` Dan Cross
@ 2023-03-12 16:40 ` Paul Winalski
2023-03-13 3:25 ` John Cowan
1 sibling, 0 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-12 16:40 UTC (permalink / raw)
To: Dan Cross; +Cc: TUHS
On 3/12/23, Dan Cross <crossd@gmail.com> wrote:
>
> It is certainly a shame that modern compiler writers have become
> essentially hostile to programmers in their pursuit of ever more aggressive
> optimizations based on rigid readings of the standard, common sense be
> damned.
As a compiler developer for many years, IMO the best compilers accept
a wide variety of variations and extensions to the language standard,
but have a strict-standard mode for those who want it.
Dave Cutler's DECwest organization developed and released s C89
compiler for Ultrix that accepted only strict, standard-conforming
syntax and semantics. No K&R mode, nothing but pure C89. One
customer called it the Rush Limbaugh of C compilers--extremely
conservative, and you can't reason with it.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-12 11:40 ` Dan Cross
2023-03-12 16:40 ` Paul Winalski
@ 2023-03-13 3:25 ` John Cowan
2023-03-13 10:40 ` Alejandro Colomar (man-pages)
1 sibling, 1 reply; 75+ messages in thread
From: John Cowan @ 2023-03-13 3:25 UTC (permalink / raw)
To: Dan Cross; +Cc: TUHS
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
On Sun, Mar 12, 2023 at 7:40 AM Dan Cross <crossd@gmail.com> wrote:
> It is certainly a shame that modern compiler writers have become
> essentially hostile to programmers in their pursuit of ever more aggressive
> optimizations based on rigid readings of the standard, common sense be
> damned.
>
Not at all. It is clear that mainstream C and C++ compilers optimize for
the features most important to mainstream C and C++ programmers, which are:
1) Execution speed.
2) Execution speed.
3) I lied; there is no 3.
If those are not your priorities, use a non-mainstream compiler or a
different programming language.
[-- Attachment #2: Type: text/html, Size: 2211 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-13 3:25 ` John Cowan
@ 2023-03-13 10:40 ` Alejandro Colomar (man-pages)
2023-03-13 12:19 ` Dan Cross
0 siblings, 1 reply; 75+ messages in thread
From: Alejandro Colomar (man-pages) @ 2023-03-13 10:40 UTC (permalink / raw)
To: John Cowan; +Cc: TUHS
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Mon, Mar 13, 2023, 04:26 John Cowan <cowan@ccil.org> wrote:
>
>
> On Sun, Mar 12, 2023 at 7:40 AM Dan Cross <crossd@gmail.com> wrote:
>
>
>> It is certainly a shame that modern compiler writers have become
>> essentially hostile to programmers in their pursuit of ever more aggressive
>> optimizations based on rigid readings of the standard, common sense be
>> damned.
>>
>
> Not at all. It is clear that mainstream C and C++ compilers optimize for
> the features most important to mainstream C and C++ programmers, which are:
>
> 1) Execution speed.
>
> 2) Execution speed.
>
> 3) I lied; there is no 3.
>
> If those are not your priorities, use a non-mainstream compiler or a
> different programming language.
>
Or you can ask GCC to respect your view of the language with things like
-fno-strict-aliasing, -fwrapv, and -fno-trapv.
>
[-- Attachment #2: Type: text/html, Size: 2916 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-13 10:40 ` Alejandro Colomar (man-pages)
@ 2023-03-13 12:19 ` Dan Cross
2023-03-13 12:43 ` [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Alejandro Colomar
0 siblings, 1 reply; 75+ messages in thread
From: Dan Cross @ 2023-03-13 12:19 UTC (permalink / raw)
To: Alejandro Colomar (man-pages); +Cc: TUHS
On Mon, Mar 13, 2023 at 6:41 AM Alejandro Colomar (man-pages)
<alx.manpages@gmail.com> wrote:
> Or you can ask GCC to respect your view of the language with things like -fno-strict-aliasing, -fwrapv, and -fno-trapv.
The problem that is that you are then no longer programming in "C",
but rather some dialect of "C" that happens to share the same syntax,
but with different semantics. That may be fine, or it may not, but it
can lead to all sorts of footgun traps if one is not careful.
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 12:19 ` Dan Cross
@ 2023-03-13 12:43 ` Alejandro Colomar
2023-03-13 12:46 ` [TUHS] " Dan Cross
2023-03-13 16:00 ` Paul Winalski
0 siblings, 2 replies; 75+ messages in thread
From: Alejandro Colomar @ 2023-03-13 12:43 UTC (permalink / raw)
To: Dan Cross; +Cc: TUHS
Hi Dan,
On 3/13/23 13:19, Dan Cross wrote:
> On Mon, Mar 13, 2023 at 6:41 AM Alejandro Colomar (man-pages)
> <alx.manpages@gmail.com> wrote:
>> Or you can ask GCC to respect your view of the language with things like -fno-strict-aliasing, -fwrapv, and -fno-trapv.
>
> The problem that is that you are then no longer programming in "C",
> but rather some dialect of "C" that happens to share the same syntax,
> but with different semantics. That may be fine, or it may not, but it
> can lead to all sorts of footgun traps if one is not careful.
Well, it depends on what you call "C". There are many dialects,
and I'm not sure there's any which I'd call "C".
The 3 main dialects are "ISO C", "GNU C", and "K&R C". And then
there are subdialects of them. We could say "C" is "ISO C", since,
well, it's _the_ standard. But then, ISO C shares the aliasing
issues that GNU C has, so by avoiding the GNU C compiler you're
not avoiding the issues we're talking about; moving to a compiler
that only talks ISO C is going to keep the issues. You'll need
a compiler that talks K&R C, or some other dialect that doesn't
have aliasing issues.
At that point, since you already need a subdialect of C, GCC is
one such compiler, since it provides a comprehensive set of flags
to tune your dialect.
Or you could move to a compiler that talks its own dialect
(probably some subdialect of K&R C, as I expect Plan9 C is, but
I never tried it). But that's not much different from asking
such dialect to GCC.
Cheers,
Alex
>
> - Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 12:43 ` [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Alejandro Colomar
@ 2023-03-13 12:46 ` Dan Cross
2023-03-13 16:00 ` Paul Winalski
1 sibling, 0 replies; 75+ messages in thread
From: Dan Cross @ 2023-03-13 12:46 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: TUHS
On Mon, Mar 13, 2023 at 8:43 AM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
> On 3/13/23 13:19, Dan Cross wrote:
> > On Mon, Mar 13, 2023 at 6:41 AM Alejandro Colomar (man-pages)
> > <alx.manpages@gmail.com> wrote:
> >> Or you can ask GCC to respect your view of the language with things like -fno-strict-aliasing, -fwrapv, and -fno-trapv.
> >
> > The problem that is that you are then no longer programming in "C",
> > but rather some dialect of "C" that happens to share the same syntax,
> > but with different semantics. That may be fine, or it may not, but it
> > can lead to all sorts of footgun traps if one is not careful.
>
> Well, it depends on what you call "C". There are many dialects,
> and I'm not sure there's any which I'd call "C".
That's precisely the problem. :-)
- Dan C.
> The 3 main dialects are "ISO C", "GNU C", and "K&R C". And then
> there are subdialects of them. We could say "C" is "ISO C", since,
> well, it's _the_ standard. But then, ISO C shares the aliasing
> issues that GNU C has, so by avoiding the GNU C compiler you're
> not avoiding the issues we're talking about; moving to a compiler
> that only talks ISO C is going to keep the issues. You'll need
> a compiler that talks K&R C, or some other dialect that doesn't
> have aliasing issues.
>
> At that point, since you already need a subdialect of C, GCC is
> one such compiler, since it provides a comprehensive set of flags
> to tune your dialect.
>
> Or you could move to a compiler that talks its own dialect
> (probably some subdialect of K&R C, as I expect Plan9 C is, but
> I never tried it). But that's not much different from asking
> such dialect to GCC.
>
> Cheers,
>
> Alex
>
> >
> > - Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 12:43 ` [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Alejandro Colomar
2023-03-13 12:46 ` [TUHS] " Dan Cross
@ 2023-03-13 16:00 ` Paul Winalski
2023-03-13 19:00 ` Clem Cole
2023-03-14 2:49 ` Theodore Ts'o
1 sibling, 2 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-13 16:00 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: TUHS
On 3/13/23, Alejandro Colomar <alx.manpages@gmail.com> wrote:
>
> Well, it depends on what you call "C". There are many dialects,
> and I'm not sure there's any which I'd call "C".
>
> The 3 main dialects are "ISO C", "GNU C", and "K&R C". And then
> there are subdialects of them. We could say "C" is "ISO C", since,
> well, it's _the_ standard.
Note that the goal of a programming language standards committee is
very different from the goal of those who use the language. The
committee's goal is to standardize existing practice of the language
in a way that is implementable on the widest range of hardware and OS
platforms, and to provide a controlled way to add language extensions.
The goal of users is to get their job done.
The advantage of programming in strict ISO C is that the resulting
code will run just about anywhere. If you don't care about that (and
I'd wager most programmers don't) then ignore the standard.
> But then, ISO C shares the aliasing
> issues that GNU C has, so by avoiding the GNU C compiler you're
> not avoiding the issues we're talking about; moving to a compiler
> that only talks ISO C is going to keep the issues. You'll need
> a compiler that talks K&R C, or some other dialect that doesn't
> have aliasing issues.
As someone pointed out, the three things that most programmers value
are execution speed, execution speed, and execution speed. Aliasing
issues greatly hamper what a modern optimizing compiler can do and
still generate semantically correct code.
> At that point, since you already need a subdialect of C, GCC is
> one such compiler, since it provides a comprehensive set of flags
> to tune your dialect.
All the best commercial optimizing compilers do that these days. It's
a way of having your semantic cake and being able to eat it (fast
execution speed), too.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 16:00 ` Paul Winalski
@ 2023-03-13 19:00 ` Clem Cole
2023-03-13 19:09 ` Larry McVoy
` (4 more replies)
2023-03-14 2:49 ` Theodore Ts'o
1 sibling, 5 replies; 75+ messages in thread
From: Clem Cole @ 2023-03-13 19:00 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
On Mon, Mar 13, 2023 at 12:00 PM Paul Winalski <paul.winalski@gmail.com>
wrote:
> ... The committee's goal is to standardize existing practice of the
> language
> in a way that is implementable on the widest range of hardware and OS
> platforms, *and to provide a controlled way to add language extensions.*
Ah, the problem, of course, is right there.
Too many people try to "fix" programming languages, particularly academics
and folks working on a new PhD. Other folks (Gnu is the best example IMO)
want to change things so the compiler writers (and it seems like the Linux
kernel developers) can do something "better" or "more easily." As someone
(I think Dan Cross) said, when that happens, it's no longer C. Without
Dennis here to say "whoa," - the committee is a tad open loop. Today's
language is hardly the language I learned before the "White Book" existed
in the early/mid 1970s. It's actually quite sad. I'm not so sure we are
"better" off.
Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
requiring and fall back at least to K&R2 -- keep it simple. The truth is
that we still use the language today is that K&R2 C was then (and still is)
good enough and got (gets) the job done extremely well. Overall, I'm not
sure all the new "features" have added all that much.
ᐧ
[-- Attachment #2: Type: text/html, Size: 2834 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 19:00 ` Clem Cole
@ 2023-03-13 19:09 ` Larry McVoy
2023-03-13 19:17 ` Steve Nickolas
` (3 subsequent siblings)
4 siblings, 0 replies; 75+ messages in thread
From: Larry McVoy @ 2023-03-13 19:09 UTC (permalink / raw)
To: Clem Cole; +Cc: Alejandro Colomar, TUHS
> Dennis without here to say "whoa," - the committee is a tad open loop.
Having someone who can say "no" is critical to any software project. What
doesn't go in is easily way more important than what does go in. You can
surround a really great idea with enough crap that all you really get is
crap.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 19:00 ` Clem Cole
2023-03-13 19:09 ` Larry McVoy
@ 2023-03-13 19:17 ` Steve Nickolas
2023-03-13 20:26 ` Dan Cross
2023-03-13 19:24 ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
` (2 subsequent siblings)
4 siblings, 1 reply; 75+ messages in thread
From: Steve Nickolas @ 2023-03-13 19:17 UTC (permalink / raw)
To: TUHS
On Mon, 13 Mar 2023, Clem Cole wrote:
> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> requiring and fall back at least to K&R2 -- keep it simple. The truth is
> that we still use the language today is that K&R2 C was then (and still is)
> good enough and got (gets) the job done extremely well. Overall, I'm not
> sure all the new "features" have added all that much.
C99 did introduce one thing I use: <stdint.h>
Beyond that, I still code strict C89. I simply treat the language itself
as ossified. I also still make assumptions about the compiler that might
not still be true, so for example
unsigned short a;
unsigned char b;
b=0xFF;
a=b<<8;
I expect to return 0 even though the logical answer is 0xFF00, and I
_always_ code it like this:
b=0xFF;
a=b;
a<<=8;
or alternatively
b=0xFF;
a=((unsigned short) b)<<8;
and there's other defensive stuff I do. I honestly don't see the point in
the other changes to the language and feel they take C away from what it
has always been.
-uso.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 19:17 ` Steve Nickolas
@ 2023-03-13 20:26 ` Dan Cross
2023-03-13 22:25 ` Alejandro Colomar (man-pages)
0 siblings, 1 reply; 75+ messages in thread
From: Dan Cross @ 2023-03-13 20:26 UTC (permalink / raw)
To: Steve Nickolas; +Cc: TUHS
On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas <usotsuki@buric.co> wrote:
> On Mon, 13 Mar 2023, Clem Cole wrote:
> > Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> > requiring and fall back at least to K&R2 -- keep it simple. The truth is
> > that we still use the language today is that K&R2 C was then (and still is)
> > good enough and got (gets) the job done extremely well. Overall, I'm not
> > sure all the new "features" have added all that much.
>
> C99 did introduce one thing I use: <stdint.h>
>
> Beyond that, I still code strict C89. I simply treat the language itself
> as ossified. I also still make assumptions about the compiler that might
> not still be true, so for example
>
> unsigned short a;
> unsigned char b;
>
> b=0xFF;
> a=b<<8;
>
> I expect to return 0 even though the logical answer is 0xFF00,
I don't know why one would expect that. `b` will be promoted to
(signed!!) `int` before the shift, and then the result of that
assigned to `a`, wrapping as needed to fit into the `unsigned short`;
on most reasonable systems the UB gods won't be angered.
OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB
minefield on most systems.
> and I
> _always_ code it like this:
>
> b=0xFF;
> a=b;
> a<<=8;
Curiously, this will be subject to the same type promotion rules as
the original.
> or alternatively
>
> b=0xFF;
> a=((unsigned short) b)<<8;
As will this. In fact, the cast here is completely superfluous; the
shift will still be done using after promotion to signed int.
> and there's other defensive stuff I do. I honestly don't see the point in
> the other changes to the language and feel they take C away from what it
> has always been.
I think an issue is that there is what people _think_ C does, and what
C _actually_ does, and the two are often discordant; this is why I
think you see people tweaking compiler options to create a dialect
that's reasonable to program in: given a large-enough code base, you
inevitably end up with a very peculiar dialect, which compounds the
problem. For example, I'm quite sure that the C dialect that Linux
uses is not the same as the C that Windows uses, and so on. The
compiler writers now seem very much of the mind where you point this
out and they look at you and say, "tough."
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 20:26 ` Dan Cross
@ 2023-03-13 22:25 ` Alejandro Colomar (man-pages)
0 siblings, 0 replies; 75+ messages in thread
From: Alejandro Colomar (man-pages) @ 2023-03-13 22:25 UTC (permalink / raw)
To: Dan Cross; +Cc: TUHS
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]
On Mon, Mar 13, 2023, 21:27 Dan Cross <crossd@gmail.com> wrote:
> On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas <usotsuki@buric.co> wrote:
> > On Mon, 13 Mar 2023, Clem Cole wrote:
> > > Frankly, I'd probably rather see ISO drop a bunch of the stuff they
> are now
> > > requiring and fall back at least to K&R2 -- keep it simple. The truth
> is
> > > that we still use the language today is that K&R2 C was then (and
> still is)
> > > good enough and got (gets) the job done extremely well. Overall,
> I'm not
> > > sure all the new "features" have added all that much.
> >
> > C99 did introduce one thing I use: <stdint.h>
> >
> > Beyond that, I still code strict C89. I simply treat the language itself
> > as ossified. I also still make assumptions about the compiler that might
> > not still be true, so for example
> >
> > unsigned short a;
> > unsigned char b;
> >
> > b=0xFF;
> > a=b<<8;
> >
> > I expect to return 0 even though the logical answer is 0xFF00,
>
> I don't know why one would expect that. `b` will be promoted to
> (signed!!) `int` before the shift, and then the result of that
> assigned to `a`, wrapping as needed to fit into the `unsigned short`;
> on most reasonable systems the UB gods won't be angered.
>
C23 will be adding new types that don't have this issue (default promotion
to in). If a variable has 3 bits, it will have 3 bits (until you mix it
with a wider variable).
Another whole class of Undefined Behavior (in ISO C) or
implementation-defined behavior (K&R C) is 2's complement arithmetic which
has never been portable, until C23. So it's not all bad.
> OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB
> minefield on most systems.
>
> > and I
> > _always_ code it like this:
> >
> > b=0xFF;
> > a=b;
> > a<<=8;
>
> Curiously, this will be subject to the same type promotion rules as
> the original.
>
> > or alternatively
> >
> > b=0xFF;
> > a=((unsigned short) b)<<8;
>
> As will this. In fact, the cast here is completely superfluous; the
> shift will still be done using after promotion to signed int.
>
> > and there's other defensive stuff I do. I honestly don't see the point
> in
> > the other changes to the language and feel they take C away from what it
> > has always been.
>
> I think an issue is that there is what people _think_ C does, and what
> C _actually_ does, and the two are often discordant;
Indeed. That's my feeling too. When discussing about features that
programmers don't understand why they were added, it's rather often the
case that the feature has been there for longer than they thought (if not
since forever).
this is why I
> think you see people tweaking compiler options to create a dialect
> that's reasonable to program in: given a large-enough code base, you
> inevitably end up with a very peculiar dialect, which compounds the
> problem. For example, I'm quite sure that the C dialect that Linux
> uses is not the same as the C that Windows uses, and so on. The
> compiler writers now seem very much of the mind where you point this
> out and they look at you and say, "tough."
>
Even "safe" Rust is having its share of Undefined Behavior. Let's see how
they deal with it.
<https://github.com/rust-lang/rust/issues/107975>
> - Dan C.
>
[-- Attachment #2: Type: text/html, Size: 4951 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects
2023-03-13 19:00 ` Clem Cole
2023-03-13 19:09 ` Larry McVoy
2023-03-13 19:17 ` Steve Nickolas
@ 2023-03-13 19:24 ` Luther Johnson
2023-03-13 19:38 ` Luther Johnson
2023-03-14 19:48 ` John Cowan
2023-03-13 20:48 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
2023-03-13 21:00 ` Paul Winalski
4 siblings, 2 replies; 75+ messages in thread
From: Luther Johnson @ 2023-03-13 19:24 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]
I agree with everything you just said here.
One of the motivations behind new dialects and languages, which I think
is very harmful, is the idea that we can and should, engineer the
necessity to know and understand what we are doing when we program in a
given language. I'm not talking about semantic leverage, higher level
languages with more abstract functions on more abstract data, there are
real benefits there, we will all probably agree to that.
I'm talking more about where the intent is to invest languages with more
"safety", "good practices", to bake certain preferences into language
features, so that writers no longer recognize these as engineering
choices, and the language as a means of expression of any choice we
might make, but that the language has built-in "the right way" to do
things, and if the program compiles and runs at all, then it must be
safe and working in certain respects.
No matter what language, craft and knowledge are not optional. The
language that we choose for a problem domain wants to give us freedom to
express our choices, while taking care of the things that wold otherwise
weigh us down. Some people would say that's exactly what the new
dialects bring us, but I see too much artificial orthodoxy invented last
week, and too many declarations of the "one true way", in many of the
most recent languages, for my taste.
On 03/13/2023 12:00 PM, Clem Cole wrote:
>
>
> On Mon, Mar 13, 2023 at 12:00 PM Paul Winalski
> <paul.winalski@gmail.com <mailto:paul.winalski@gmail.com>> wrote:
>
> ... Thecommittee's goal is to standardize existing practice of the
> language
> in a way that is implementable on the widest range of hardware and OS
> platforms, _/and to provide a controlled way to add language
> extensions./_
>
> Ah, the problem, of course, is right there.
>
> Too many people try to "fix" programming languages, particularly
> academics and folks working on a new PhD. Other folks (Gnu is the best
> example IMO) want to change things so the compiler writers (and it
> seems like the Linux kernel developers) can do something "better" or
> "more easily." As someone (I think Dan Cross) said, when that happens,
> it's no longer C. Without Dennis here to say "whoa," - the
> committee is a tad open loop. Today's language is hardly the
> language I learned before the "White Book" existed in the early/mid
> 1970s. It's actually quite sad. I'm not so sure we are "better" off.
>
> Frankly, I'd probably rather see ISO drop a bunch of the stuff they
> are now requiring and fall back at least to K&R2 -- keep it simple.
> The truth is that we still use the language today is that K&R2 C was
> then (and still is) good enough and got (gets) the job done extremely
> well. Overall, I'm not sure all the new "features" have added all that
> much.
> ᐧ
[-- Attachment #2: Type: text/html, Size: 5572 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects
2023-03-13 19:24 ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
@ 2023-03-13 19:38 ` Luther Johnson
2023-03-14 19:48 ` John Cowan
1 sibling, 0 replies; 75+ messages in thread
From: Luther Johnson @ 2023-03-13 19:38 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]
I meant to say engineer "out" the necessity ...doh ! I shot myself in
the foot there ...
On 03/13/2023 12:24 PM, Luther Johnson wrote:
>
> I agree with everything you just said here.
>
> One of the motivations behind new dialects and languages, which I
> think is very harmful, is the idea that we can and should, engineer
> the necessity to know and understand what we are doing when we program
> in a given language. I'm not talking about semantic leverage, higher
> level languages with more abstract functions on more abstract data,
> there are real benefits there, we will all probably agree to that.
>
> I'm talking more about where the intent is to invest languages with
> more "safety", "good practices", to bake certain preferences into
> language features, so that writers no longer recognize these as
> engineering choices, and the language as a means of expression of any
> choice we might make, but that the language has built-in "the right
> way" to do things, and if the program compiles and runs at all, then
> it must be safe and working in certain respects.
>
> No matter what language, craft and knowledge are not optional. The
> language that we choose for a problem domain wants to give us freedom
> to express our choices, while taking care of the things that wold
> otherwise weigh us down. Some people would say that's exactly what the
> new dialects bring us, but I see too much artificial orthodoxy
> invented last week, and too many declarations of the "one true way",
> in many of the most recent languages, for my taste.
>
> On 03/13/2023 12:00 PM, Clem Cole wrote:
>>
>>
>> On Mon, Mar 13, 2023 at 12:00 PM Paul Winalski
>> <paul.winalski@gmail.com <mailto:paul.winalski@gmail.com>> wrote:
>>
>> ... Thecommittee's goal is to standardize existing practice of
>> the language
>> in a way that is implementable on the widest range of hardware and OS
>> platforms, _/and to provide a controlled way to add language
>> extensions./_
>>
>> Ah, the problem, of course, is right there.
>>
>> Too many people try to "fix" programming languages, particularly
>> academics and folks working on a new PhD. Other folks (Gnu is the
>> best example IMO) want to change things so the compiler writers (and
>> it seems like the Linux kernel developers) can do something "better"
>> or "more easily." As someone (I think Dan Cross) said, when that
>> happens, it's no longer C. Without Dennis here to say "whoa," - the
>> committee is a tad open loop. Today's language is hardly the
>> language I learned before the "White Book" existed in the early/mid
>> 1970s. It's actually quite sad. I'm not so sure we are "better" off.
>>
>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they
>> are now requiring and fall back at least to K&R2 -- keep it simple.
>> The truth is that we still use the language today is that K&R2 C was
>> then (and still is) good enough and got (gets) the job done extremely
>> well. Overall, I'm not sure all the new "features" have added all
>> that much.
>> ᐧ
>
[-- Attachment #2: Type: text/html, Size: 6221 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects
2023-03-13 19:24 ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
2023-03-13 19:38 ` Luther Johnson
@ 2023-03-14 19:48 ` John Cowan
2023-03-14 19:56 ` Joseph Holsten
2023-03-14 20:01 ` Luther Johnson
1 sibling, 2 replies; 75+ messages in thread
From: John Cowan @ 2023-03-14 19:48 UTC (permalink / raw)
To: Luther Johnson; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com> wrote:
> I'm talking more about where the intent is to invest languages with more
> "safety", "good practices", to bake certain preferences into language
> features, so that writers no longer recognize these as engineering choices,
> and the language as a means of expression of any choice we might make, but
> that the language has built-in "the right way" to do things, and if the
> program compiles and runs at all, then it must be safe and working in
> certain respects.
>
ORLY? Do you reject C, then, because it does not support self-modifying
code or the ability to jump into the middle of a procedure without going
through the prologue? These are baked-in preferences, and if a C program
compiles at all, you can be sure that it does neither of these things, even
if it would benefit your program greatly if they were available.
Some people would say that's exactly what the new dialects bring us, but I
> see too much artificial orthodoxy invented last week, and too many
> declarations of the "one true way", in many of the most recent languages,
> for my taste.
>
Since you agree that it is a matter of taste, there can of course be no
disputing it.
[-- Attachment #2: Type: text/html, Size: 2286 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects
2023-03-14 19:48 ` John Cowan
@ 2023-03-14 19:56 ` Joseph Holsten
2023-03-14 20:01 ` Luther Johnson
1 sibling, 0 replies; 75+ messages in thread
From: Joseph Holsten @ 2023-03-14 19:56 UTC (permalink / raw)
To: Tautological Eunuch Horticultural Scythians
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
Is TUHS still the right place for this discussion?
On Tue, Mar 14, 2023, at 12:48, John Cowan wrote:
>
>
> On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com> wrote:
>> I'm talking more about where the intent is to invest languages with more "safety", "good practices", to bake certain preferences into language features, so that writers no longer recognize these as engineering choices, and the language as a means of expression of any choice we might make, but that the language has built-in "the right way" to do things, and if the program compiles and runs at all, then it must be safe and working in certain respects.
>>
>
> ORLY? Do you reject C, then, because it does not support self-modifying code or the ability to jump into the middle of a procedure without going through the prologue? These are baked-in preferences, and if a C program compiles at all, you can be sure that it does neither of these things, even if it would benefit your program greatly if they were available.
>
>> Some people would say that's exactly what the new dialects bring us, but I see too much artificial orthodoxy invented last week, and too many declarations of the "one true way", in many of the most recent languages, for my taste.
>
> Since you agree that it is a matter of taste, there can of course be no disputing it.
[-- Attachment #2: Type: text/html, Size: 2792 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects
2023-03-14 19:48 ` John Cowan
2023-03-14 19:56 ` Joseph Holsten
@ 2023-03-14 20:01 ` Luther Johnson
1 sibling, 0 replies; 75+ messages in thread
From: Luther Johnson @ 2023-03-14 20:01 UTC (permalink / raw)
To: John Cowan; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
I take your points. C gives a lot of freedom, but all things are not
possible. I think what comes to mind for me is when I see the idea of
trying to limit solutions to use only certain certain "design patterns",
I usually would go in the direction of more freedom and less rules.
On 03/14/2023 12:48 PM, John Cowan wrote:
>
>
> On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com
> <mailto:luther@makerlisp.com>> wrote:
>
> I'm talking more about where the intent is to invest languages
> with more "safety", "good practices", to bake certain preferences
> into language features, so that writers no longer recognize these
> as engineering choices, and the language as a means of expression
> of any choice we might make, but that the language has built-in
> "the right way" to do things, and if the program compiles and runs
> at all, then it must be safe and working in certain respects.
>
>
> ORLY? Do you reject C, then, because it does not support
> self-modifying code or the ability to jump into the middle of a
> procedure without going through the prologue? These are baked-in
> preferences, and if a C program compiles at all, you can be sure that
> it does neither of these things, even if it would benefit your program
> greatly if they were available.
>
> Some people would say that's exactly what the new dialects bring
> us, but I see too much artificial orthodoxy invented last week,
> and too many declarations of the "one true way", in many of the
> most recent languages, for my taste.
>
>
> Since you agree that it is a matter of taste, there can of course be
> no disputing it.
[-- Attachment #2: Type: text/html, Size: 3721 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 19:00 ` Clem Cole
` (2 preceding siblings ...)
2023-03-13 19:24 ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
@ 2023-03-13 20:48 ` Paul Winalski
2023-03-13 20:56 ` Bakul Shah
2023-03-14 1:06 ` Larry McVoy
2023-03-13 21:00 ` Paul Winalski
4 siblings, 2 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-13 20:48 UTC (permalink / raw)
To: Clem Cole; +Cc: Alejandro Colomar, TUHS
On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>
> Too many people try to "fix" programming languages, particularly academics
> and folks working on a new PhD. Other folks (Gnu is the best example IMO)
> want to change things so the compiler writers (and it seems like the Linux
> kernel developers) can do something "better" or "more easily." As someone
> (I think Dan Cross) said, when that happens, it's no longer C. Without
> Dennis here to say "whoa," - the committee is a tad open loop. Today's
> language is hardly the language I learned before the "White Book" existed
> in the early/mid 1970s. It's actually quite sad. I'm not so sure we are
> "better" off.
I'd rather see programming language standards committees restrict
their activity to regularizing existing practice. Let vendors and
others innovate by adding non-standard extensions. Then take those
that are really useful and adopt them as part of the standard. But
the committee itself should not be doing design. We all know what
they say about "design by committee", and it's all too true.
Programming language standards committees also tend to suffer from
what I call the "dog and fire hydrant" problem. The committee members
are like a pack of dogs, with the standard being the fire hydrant.
Each dog doesn't consider the fire hydrant "theirs" until they've
pissed on it. Programming languages get treated the same way by
standards committee members.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 20:48 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
@ 2023-03-13 20:56 ` Bakul Shah
2023-03-14 1:06 ` Larry McVoy
1 sibling, 0 replies; 75+ messages in thread
From: Bakul Shah @ 2023-03-13 20:56 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
In hindsight Algol68 may have been the last committee designed
language that was good. It got a lot of flack back then but its
imperfections seem tiny in comparison to most of the languages
designed since then.
> On Mar 13, 2023, at 1:48 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> I'd rather see programming language standards committees restrict
> their activity to regularizing existing practice. Let vendors and
> others innovate by adding non-standard extensions. Then take those
> that are really useful and adopt them as part of the standard. But
> the committee itself should not be doing design. We all know what
> they say about "design by committee", and it's all too true.
>
> Programming language standards committees also tend to suffer from
> what I call the "dog and fire hydrant" problem. The committee members
> are like a pack of dogs, with the standard being the fire hydrant.
> Each dog doesn't consider the fire hydrant "theirs" until they've
> pissed on it. Programming languages get treated the same way by
> standards committee members.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 20:48 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
2023-03-13 20:56 ` Bakul Shah
@ 2023-03-14 1:06 ` Larry McVoy
1 sibling, 0 replies; 75+ messages in thread
From: Larry McVoy @ 2023-03-14 1:06 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
On Mon, Mar 13, 2023 at 04:48:04PM -0400, Paul Winalski wrote:
> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
> >
> > Too many people try to "fix" programming languages, particularly academics
> > and folks working on a new PhD. Other folks (Gnu is the best example IMO)
> > want to change things so the compiler writers (and it seems like the Linux
> > kernel developers) can do something "better" or "more easily." As someone
> > (I think Dan Cross) said, when that happens, it's no longer C. Without
> > Dennis here to say "whoa," - the committee is a tad open loop. Today's
> > language is hardly the language I learned before the "White Book" existed
> > in the early/mid 1970s. It's actually quite sad. I'm not so sure we are
> > "better" off.
>
> I'd rather see programming language standards committees restrict
> their activity to regularizing existing practice. Let vendors and
> others innovate by adding non-standard extensions. Then take those
> that are really useful and adopt them as part of the standard. But
> the committee itself should not be doing design. We all know what
> they say about "design by committee", and it's all too true.
I wish I had a magic wand and could upvote this more. You are exactly
right, that is exactly what standards should do, maybe with a little
leeway to resolve conflicts between 2 good ideas, but no more than
that.
But ego gets involved and things go pear shaped.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 19:00 ` Clem Cole
` (3 preceding siblings ...)
2023-03-13 20:48 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
@ 2023-03-13 21:00 ` Paul Winalski
2023-03-13 21:07 ` Bakul Shah
2023-03-14 0:38 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) John Cowan
4 siblings, 2 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-13 21:00 UTC (permalink / raw)
To: Clem Cole; +Cc: Alejandro Colomar, TUHS
On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>
> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> requiring and fall back at least to K&R2 -- keep it simple.
I agree. Every language has toxic features--things that seemed like
good ideas at the time but turn out to have been mistakes when they're
better understood. Every good programming shop has its rules
concerning certain language features or practices that are not allowed
in the code, usually for safety or maintainability reasons.
Dropping toxic features from a language does happen at standards
committees, but it's rare. The best case I know of where this
happened was when the international standard for PL/I came out. They
started with IBM PL/I but then dropped a bunch of features that were
either obsolete (e.g., sterling pictures) or downright dangerous
(e.g., the DEFAULT statement).
On the other side of the spectrum you have the BASIC standards
committee. BASIC has always had to live down a reputation that it's a
"toy language" not suitable for "serious programming". The standards
committee seems to have suffered from an inferiority complex, and it
seemed from my perspective that as fast as the PL/I committee chucked
out toxic language, the BASIC committee adopted them. The result is a
bloated, grotesque monstrosity that little resembles the simple, clean
Dartmouth BASIC 6 that was the first programming language I learned
(from the DTSS TEACH command).
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:00 ` Paul Winalski
@ 2023-03-13 21:07 ` Bakul Shah
2023-03-13 21:14 ` Dan Cross
` (2 more replies)
2023-03-14 0:38 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) John Cowan
1 sibling, 3 replies; 75+ messages in thread
From: Bakul Shah @ 2023-03-13 21:07 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>>
>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
>> requiring and fall back at least to K&R2 -- keep it simple.
>
> I agree. Every language has toxic features--things that seemed like
> good ideas at the time but turn out to have been mistakes when they're
> better understood. Every good programming shop has its rules
> concerning certain language features or practices that are not allowed
> in the code, usually for safety or maintainability reasons.
You can't drop features from a widely deployed language; but while
we are dreaming, what I'd like to see is a total *ban* on any and
all optimizations. What you get is what you see!
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:07 ` Bakul Shah
@ 2023-03-13 21:14 ` Dan Cross
2023-03-13 22:15 ` Dave Horsfall
2023-03-14 1:27 ` Bakul Shah
2023-03-13 21:28 ` Paul Winalski
2023-03-14 10:04 ` [TUHS] C dialects Ralph Corderoy
2 siblings, 2 replies; 75+ messages in thread
From: Dan Cross @ 2023-03-13 21:14 UTC (permalink / raw)
To: Bakul Shah; +Cc: Alejandro Colomar, TUHS
On Mon, Mar 13, 2023 at 5:08 PM Bakul Shah <bakul@iitbombay.org> wrote:
> On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> >
> > On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
> >>
> >> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> >> requiring and fall back at least to K&R2 -- keep it simple.
> >
> > I agree. Every language has toxic features--things that seemed like
> > good ideas at the time but turn out to have been mistakes when they're
> > better understood. Every good programming shop has its rules
> > concerning certain language features or practices that are not allowed
> > in the code, usually for safety or maintainability reasons.
>
> You can't drop features from a widely deployed language; but while
> we are dreaming, what I'd like to see is a total *ban* on any and
> all optimizations. What you get is what you see!
Hey, they dropped `gets` from the standard library! Never say never.
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:14 ` Dan Cross
@ 2023-03-13 22:15 ` Dave Horsfall
2023-03-13 22:47 ` Dave Horsfall
2023-03-14 0:21 ` Dan Cross
2023-03-14 1:27 ` Bakul Shah
1 sibling, 2 replies; 75+ messages in thread
From: Dave Horsfall @ 2023-03-13 22:15 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Mon, 13 Mar 2023, Dan Cross wrote:
> Hey, they dropped `gets` from the standard library! Never say never.
When did that finally happen? Last I looked, gets() was still part of
POSIX, and hence couldn't be dropped...
Trivia: I think it was OpenBSD that nobbled gets() to print a warning
whenever it was invoked :-)
-- Dave
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 22:15 ` Dave Horsfall
@ 2023-03-13 22:47 ` Dave Horsfall
2023-03-14 0:23 ` Dan Cross
2023-03-14 0:21 ` Dan Cross
1 sibling, 1 reply; 75+ messages in thread
From: Dave Horsfall @ 2023-03-13 22:47 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Tue, 14 Mar 2023, Dave Horsfall followed himself up:
> Trivia: I think it was OpenBSD that nobbled gets() to print a warning
> whenever it was invoked :-)
FreeBSD 10.4 (old, I know):
c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main()
^~~~
c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
[-Wimplicit-function-declaration]
{ gets(); }
^
2 warnings generated.
/tmp/c-36bc21.o: In function `main':
c.c:(.text+0x4): warning: warning: this program uses gets(), which is unsafe.
aneurin% ./c
warning: this program uses gets(), which is unsafe.
<CR>
aneurin%
On the MacBook (10.13.6 High Sierra):
c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main()
^
c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
[-Wimplicit-function-declaration]
{ gets(); }
^
2 warnings generated.
mackie:tmp dave$ ./c
warning: this program uses gets(), which is unsafe.
<CR>
And it core-dumped,,,
(I don't have access to my Penguin/OS lapdog right now.)
I think that it's trying to tel me something :-)
-- Dave
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 22:47 ` Dave Horsfall
@ 2023-03-14 0:23 ` Dan Cross
0 siblings, 0 replies; 75+ messages in thread
From: Dan Cross @ 2023-03-14 0:23 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On Mon, Mar 13, 2023 at 6:47 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Tue, 14 Mar 2023, Dave Horsfall followed himself up:
>
> > Trivia: I think it was OpenBSD that nobbled gets() to print a warning
> > whenever it was invoked :-)
>
> FreeBSD 10.4 (old, I know):
>
> c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main()
> ^~~~
> c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
> [-Wimplicit-function-declaration]
> { gets(); }
> ^
> 2 warnings generated.
> /tmp/c-36bc21.o: In function `main':
> c.c:(.text+0x4): warning: warning: this program uses gets(), which is unsafe.
> aneurin% ./c
> warning: this program uses gets(), which is unsafe.
> <CR>
> aneurin%
>
> On the MacBook (10.13.6 High Sierra):
>
> c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> main()
> ^
> c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
> [-Wimplicit-function-declaration]
> { gets(); }
> ^
> 2 warnings generated.
> mackie:tmp dave$ ./c
> warning: this program uses gets(), which is unsafe.
> <CR>
>
> And it core-dumped,,,
I should hope so! It takes a pointer to a buffer as an argument, and
it appears you elided that. :-D
> (I don't have access to my Penguin/OS lapdog right now.)
>
> I think that it's trying to tel me something :-)
gets: unsafe at any C.
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 22:15 ` Dave Horsfall
2023-03-13 22:47 ` Dave Horsfall
@ 2023-03-14 0:21 ` Dan Cross
2023-03-14 13:52 ` Chet Ramey
1 sibling, 1 reply; 75+ messages in thread
From: Dan Cross @ 2023-03-14 0:21 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On Mon, Mar 13, 2023 at 6:15 PM Dave Horsfall <dave@horsfall.org> wrote:
> On Mon, 13 Mar 2023, Dan Cross wrote:
> > Hey, they dropped `gets` from the standard library! Never say never.
>
> When did that finally happen? Last I looked, gets() was still part of
> POSIX, and hence couldn't be dropped...
It was (finally!!) dropped from ISO C in C11.
It's a shame POSIX is keeping it around, but it appears you're right:
https://pubs.opengroup.org/onlinepubs/9699919799/
In fairness, this does say it may be removed from a later standard.
- Dan C.
> Trivia: I think it was OpenBSD that nobbled gets() to print a warning
> whenever it was invoked :-)
>
> -- Dave
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:14 ` Dan Cross
2023-03-13 22:15 ` Dave Horsfall
@ 2023-03-14 1:27 ` Bakul Shah
1 sibling, 0 replies; 75+ messages in thread
From: Bakul Shah @ 2023-03-14 1:27 UTC (permalink / raw)
To: Dan Cross; +Cc: Alejandro Colomar, TUHS
On Mar 13, 2023, at 2:14 PM, Dan Cross <crossd@gmail.com> wrote:
>
> On Mon, Mar 13, 2023 at 5:08 PM Bakul Shah <bakul@iitbombay.org> wrote:
>> On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>>>
>>> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>>>>
>>>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
>>>> requiring and fall back at least to K&R2 -- keep it simple.
>>>
>>> I agree. Every language has toxic features--things that seemed like
>>> good ideas at the time but turn out to have been mistakes when they're
>>> better understood. Every good programming shop has its rules
>>> concerning certain language features or practices that are not allowed
>>> in the code, usually for safety or maintainability reasons.
>>
>> You can't drop features from a widely deployed language; but while
>> we are dreaming, what I'd like to see is a total *ban* on any and
>> all optimizations. What you get is what you see!
>
> Hey, they dropped `gets` from the standard library! Never say never.
It is easy to see that incorrect use of gets can lead to buffer
overflow problems so they "fixed" the easier downstream issue but
not the root cause! And that is the problem. Easy things are fixed
but nobody dares fix more fundamental problems.
And that was my point. All that standardization committees can do
is tweak a few things here and there.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:07 ` Bakul Shah
2023-03-13 21:14 ` Dan Cross
@ 2023-03-13 21:28 ` Paul Winalski
2023-03-14 10:04 ` [TUHS] C dialects Ralph Corderoy
2 siblings, 0 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-13 21:28 UTC (permalink / raw)
To: Bakul Shah; +Cc: Alejandro Colomar, TUHS
On 3/13/23, Bakul Shah <bakul@iitbombay.org> wrote:
>
> You can't drop features from a widely deployed language;
It has been done, with advanced warning of the deprecation, and over
several iterations of the standard so that there's advanced warning.
But it's rare and not advisable.
But you can create new subsets of the full standard.
> but while
> we are dreaming, what I'd like to see is a total *ban* on any and
> all optimizations. What you get is what you see!
>
Be careful what you wish for. That just won't fly on modern computer
architectures, with their many execution units and complicated memory
hierarchies. Not if you want anything resembling reasonable
performance that is also maintainable.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] C dialects
2023-03-13 21:07 ` Bakul Shah
2023-03-13 21:14 ` Dan Cross
2023-03-13 21:28 ` Paul Winalski
@ 2023-03-14 10:04 ` Ralph Corderoy
2023-03-14 20:02 ` [TUHS] " John Cowan
2 siblings, 1 reply; 75+ messages in thread
From: Ralph Corderoy @ 2023-03-14 10:04 UTC (permalink / raw)
To: tuhs
Hi Bakul,
> ...what I'd like to see is a total *ban* on any and all optimizations.
> What you get is what you see!
I think you'd see less clear source code as, once again, programmers
chased efficiency by contorting the source to squeeze the best out of a
dumb compiler.
I think Ted said it well.
Let the compiler squeeze all it can out of the letter of the standard.
Let the programmer have the compiler abide by the spirit of the language.
--
Cheers, Ralph.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 21:00 ` Paul Winalski
2023-03-13 21:07 ` Bakul Shah
@ 2023-03-14 0:38 ` John Cowan
1 sibling, 0 replies; 75+ messages in thread
From: John Cowan @ 2023-03-14 0:38 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
On Mon, Mar 13, 2023 at 5:00 PM Paul Winalski <paul.winalski@gmail.com>
wrote:
Dropping toxic features from a language does happen at standards
> committees, but it's rare. The best case I know of where this
> happened was when the international standard for PL/I came out. They
> started with IBM PL/I but then dropped a bunch of features that were
> either obsolete (e.g., sterling pictures) or downright dangerous
> (e.g., the DEFAULT statement).
>
That actually happened twice. The 1976 standard removed features from IBM
PL/I; the 1981 Subset G standard removed even more features. (A few were
added back in the 1987 revision of Subset G.)
> On the other side of the spectrum you have the BASIC standards
> committee. BASIC has always had to live down a reputation that it's a
> "toy language" not suitable for "serious programming". The standards
> committee seems to have suffered from an inferiority complex, and it
> seemed from my perspective that as fast as the PL/I committee chucked
> out toxic language, the BASIC committee adopted them.
There are two Basic standards as well: the smaller one came first.
[-- Attachment #2: Type: text/html, Size: 2223 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-13 16:00 ` Paul Winalski
2023-03-13 19:00 ` Clem Cole
@ 2023-03-14 2:49 ` Theodore Ts'o
2023-03-14 3:06 ` G. Branden Robinson
1 sibling, 1 reply; 75+ messages in thread
From: Theodore Ts'o @ 2023-03-14 2:49 UTC (permalink / raw)
To: Paul Winalski; +Cc: Alejandro Colomar, TUHS
On Mon, Mar 13, 2023 at 12:00:04PM -0400, Paul Winalski wrote:
>
> Note that the goal of a programming language standards committee is
> very different from the goal of those who use the language. The
> committee's goal is to standardize existing practice of the language
> in a way that is implementable on the widest range of hardware and OS
> platforms, and to provide a controlled way to add language extensions.
It's worse than that. Programming language stanrds committees are
dominated by engineers working on compilers, and there are very few (I
personally know of only one) OS engineers who might be trying to *use*
the language in a kernel where you have interrupt handlers, etc., and
don't like the fact that the compiler might optimize the code in such
a way that it moves instructions out from a critical region, etc.
> The advantage of programming in strict ISO C is that the resulting
> code will run just about anywhere. If you don't care about that (and
> I'd wager most programmers don't) then ignore the standard.
For a sufficiently important program, it's possible for the authors to
say --- the C standard is just ***insane*** and if you want us to
support compilation of say, the Linux kernel by your compiler, you
*must* provide knobs to turn off certain insane "features" of the C
language spec. GCC and Clang have those knobs, so you could say that
it they support the Linux kernel "dialect". And the fact that this
dialect isn't blessed by the ISO committee doesn't cause me to lose
any sleep at night.
> As someone pointed out, the three things that most programmers value
> are execution speed, execution speed, and execution speed. Aliasing
> issues greatly hamper what a modern optimizing compiler can do and
> still generate semantically correct code.
Compiler companies who are playing benchmark wars care about execution
speed --- of benchmark programs. I'm not sure how many programmers
actually care about some of these optimizations, because there aren't
*that* many programs that are really CPU bound, and many which appear
to be CPU bound are often hitting memory bandwidth / caching issues,
which are not necessarily the things which tricky compiler
optimizations can fix.
As an OS engineer, I deeply despise these optimization tricks, since I
personally I care about correctness and not corrupting user data far
more than I care about execution speed ---- especially when the parts
of the kernel I work on tend not to be CPU bound in the first place.
- Ted
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
2023-03-14 2:49 ` Theodore Ts'o
@ 2023-03-14 3:06 ` G. Branden Robinson
0 siblings, 0 replies; 75+ messages in thread
From: G. Branden Robinson @ 2023-03-14 3:06 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Alejandro Colomar, TUHS
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]
At 2023-03-13T22:49:23-0400, Theodore Ts'o wrote:
> As an OS engineer, I deeply despise these optimization tricks, since I
> personally I care about correctness and not corrupting user data far
> more than I care about execution speed ---- especially when the parts
> of the kernel I work on tend not to be CPU bound in the first place.
Alex has heard me say this before.
In the U.S., civilian air traffic controllers have a maxim.
Safe, orderly, efficient.[1]
You meet these criteria in order from left to right, and you satisfy one
completely, or to some accepted, documented, and well-known standard
measure, before you move on to the next. The obvious reason for this is
that when aircraft meet each other at cruise altitudes, many people die.
I haven't yet settled on a counterpart for software engineering that I
like, but the best stab at it I've come up with is this.
Comprehensible, correct, efficient.
Incomprehensible code is useless.[2][3] Even code that is proven
correct by formal methods is fragile if human maintainers are defeated
by its esoteric expression.[4] (And formal verification can't save you
from incorrect specification in the first place.) Richard Feynman once
said something along the lines of, if there is any phenomenon in physics
that he can't successfully explain to an audience of freshmen, then we
don't really understand it yet. We use subtle, complex tools to solve
problems only when we haven't worked out ways to overcome them with
simple, straightforward ones. Before we surrender to the excuse of
irreducible complexity we must have valid, verifiable, peer-reproducible
evidence that we've reduced the complexity as far as known methods will
allow.
But I'm junior to most of the grognards are on this list, so I'm
half-expecting the Joe Pesci opening statement from _My Cousin Vinny_...
Regards,
Branden
[1] https://www.avweb.com/features/say-again-8air-traffic-chaos/
[2] Literally useless, especially once that something that "just works"
is ported to a new context. "The real problem is that we didn't
understand what was going on either."
https://www.bell-labs.com/usr/dmr/www/odd.html
[3] Except for constructing streams of self-lauding horse puckey before
promotion committees comprised of people who themselves attained,
and will further advance, their status predicated on the audacity of
their horse puckey.
[4] And once something's _that_ solid, it may be time to consider
etching it in silicon rather than primary or secondary storage.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
@ 2023-03-10 15:37 Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
` (2 more replies)
0 siblings, 3 replies; 75+ messages in thread
From: Noel Chiappa @ 2023-03-10 15:37 UTC (permalink / raw)
To: tuhs
> From: "Ronald Natalie"
> Multilevel breaks are as bad as goto with regard to structure violation.
In a way, you are right. There isn't really much difference between:
for (mumble) {
for (foobar) {
do some stuff
break-2;
}
}
and:
for (mumble) {
for (foobar) {
do some stuff
goto all_loops_done;
}
}
all_loops_done:
The former is basically just 'syntactic sugar' for the latter.
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Then, of course, one gets into the usual shrubbery of 'but suppose someone
uses them in a way that's _not_ structured?' There's no fixing stupid, is my
response. Nested 'if/then/else' can be used to write comletely
incomprehensible code (I have an amusing story about that) - but that's not
an argument against nested 'if/then/else'.
As I've said before, the best sculpting tools in the world won't make a great
sculptor out of a ham-handed bozo.
Noel
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 15:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
@ 2023-03-10 15:46 ` Larry McVoy
2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2 siblings, 0 replies; 75+ messages in thread
From: Larry McVoy @ 2023-03-10 15:46 UTC (permalink / raw)
To: Noel Chiappa; +Cc: tuhs
I've used gotos for decades but in a "structured" way. My functions
have a pattern:
<allocation section>
<work section>
<deallocation section>
and there are a series of labels in the deallocation section. Then while
you are wandering through the allocation section, you can jump to the
right spot in the deallocation section.
And yes, this is a simplification because I initialize all my pointers to
NULL so the deallocation is all
if (p) free(p);
but the idea is the same. You wind up some state and wind down some state
and the gotos are used to jump to the right place to unwind.
On Fri, Mar 10, 2023 at 10:37:02AM -0500, Noel Chiappa wrote:
> > From: "Ronald Natalie"
>
> > Multilevel breaks are as bad as goto with regard to structure violation.
>
> In a way, you are right. There isn't really much difference between:
>
> for (mumble) {
> for (foobar) {
> do some stuff
> break-2;
> }
> }
>
> and:
>
> for (mumble) {
> for (foobar) {
> do some stuff
> goto all_loops_done;
> }
> }
> all_loops_done:
>
>
> The former is basically just 'syntactic sugar' for the latter.
>
> I think the point is that goto's aren't necessarily _always_ bad, in and of
> themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
> in a _structured_ way (oxymoronic as that sounds), to get around things that
> are lacking in the language's flow-control, they're probably fine.
>
> Then, of course, one gets into the usual shrubbery of 'but suppose someone
> uses them in a way that's _not_ structured?' There's no fixing stupid, is my
> response. Nested 'if/then/else' can be used to write comletely
> incomprehensible code (I have an amusing story about that) - but that's not
> an argument against nested 'if/then/else'.
>
> As I've said before, the best sculpting tools in the world won't make a great
> sculptor out of a ham-handed bozo.
>
> Noel
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 15:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
@ 2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2 siblings, 0 replies; 75+ messages in thread
From: Dan Cross @ 2023-03-10 16:04 UTC (permalink / raw)
To: Noel Chiappa; +Cc: tuhs
On Fri, Mar 10, 2023 at 10:37 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>[snip]
> I think the point is that goto's aren't necessarily _always_ bad, in and of
> themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
> in a _structured_ way (oxymoronic as that sounds), to get around things that
> are lacking in the language's flow-control, they're probably fine.
Something that I think was likely a useful outcome of Djikstra's
polemic is that people began looking at what they were using goto for
and the things that were useful were extracted and codified as
first-class mechanisms in lots of languages (e.g., `break` and
`continue` for loops; exceptions; early function returns;
multilevel-break where that's a thing in a particular language, etc).
Goto is sort of like a hammer stone, it's useful for all kinds of
things, but it's difficult to control without practice and patience.
You can probably cut a diamond with one, but why endure the difficulty
and take the risk if you have access to a jeweler's hammer?
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 15:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
2023-03-10 16:04 ` Dan Cross
@ 2023-03-10 18:55 ` Ron Natalie
2023-03-10 19:04 ` Dan Cross
2 siblings, 1 reply; 75+ messages in thread
From: Ron Natalie @ 2023-03-10 18:55 UTC (permalink / raw)
To: Noel Chiappa, tuhs
That’s my point. Both break structure.
Just hinding the break with some construct that isn’t “goto” doesn’t
make it acceptable.
------ Original Message ------
From "Noel Chiappa" <jnc@mercury.lcs.mit.edu>
To tuhs@tuhs.org
Date 3/10/2023 10:37:02 AM
Subject [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th
anniversary
> > From: "Ronald Natalie"
>
> > Multilevel breaks are as bad as goto with regard to structure violation.
>
>In a way, you are right. There isn't really much difference between:
>
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 18:55 ` Ron Natalie
@ 2023-03-10 19:04 ` Dan Cross
2023-03-10 19:35 ` segaloco via TUHS
0 siblings, 1 reply; 75+ messages in thread
From: Dan Cross @ 2023-03-10 19:04 UTC (permalink / raw)
To: Ron Natalie; +Cc: Noel Chiappa, tuhs
On Fri, Mar 10, 2023 at 1:55 PM Ron Natalie <ron@ronnatalie.com> wrote:
> That’s my point. Both break structure.
>
> Just hinding the break with some construct that isn’t “goto” doesn’t
> make it acceptable.
The alternative is often worse, though. I'd take a well-aimed goto or
a nested break over a bunch of conditionals in the bodies of loops any
day, both in terms of readability and performance.
That said, I'm not a huge fan of the `goto fail;` pattern. Apple had a
pretty major bug with that, and I find that many, many times it can be
replaced with a restructuring of the code. For example, perhaps do
your allocation, call a function and capture the return value (passing
the allocated resources as arguments), and then de-allocate and return
the cached return value. Let the compiler optimize it.
As an experiment, I rewrote the Apple bug code (which was open source)
to do that and it was cleaner and simpler than the original. Someone I
showed it to said, "but what, are you going to do that for _every_
function that can fail?" Well no, but generally you don't have to; we
fixate too much on the general problem and ignore the specifics.
- Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 19:04 ` Dan Cross
@ 2023-03-10 19:35 ` segaloco via TUHS
0 siblings, 0 replies; 75+ messages in thread
From: segaloco via TUHS @ 2023-03-10 19:35 UTC (permalink / raw)
To: Dan Cross; +Cc: Noel Chiappa, tuhs
That's a good point about the specifics, there's no one-size-fits-all error condition that describes every possible exceptional circumstance, so how could there be one singular best practice for handling the abstract concept of an "error".
Plus, given one person's error is another person's business logic sometimes...if we can't agree on what an error is, how can a computer be expected to :P
- Matt G.
------- Original Message -------
On Friday, March 10th, 2023 at 11:04 AM, Dan Cross <crossd@gmail.com> wrote:
> On Fri, Mar 10, 2023 at 1:55 PM Ron Natalie ron@ronnatalie.com wrote:
>
> > That’s my point. Both break structure.
> >
> > Just hinding the break with some construct that isn’t “goto” doesn’t
> > make it acceptable.
>
>
> The alternative is often worse, though. I'd take a well-aimed goto or
> a nested break over a bunch of conditionals in the bodies of loops any
> day, both in terms of readability and performance.
>
> That said, I'm not a huge fan of the `goto fail;` pattern. Apple had a
> pretty major bug with that, and I find that many, many times it can be
> replaced with a restructuring of the code. For example, perhaps do
> your allocation, call a function and capture the return value (passing
> the allocated resources as arguments), and then de-allocate and return
> the cached return value. Let the compiler optimize it.
>
> As an experiment, I rewrote the Apple bug code (which was open source)
> to do that and it was cleaner and simpler than the original. Someone I
> showed it to said, "but what, are you going to do that for every
> function that can fail?" Well no, but generally you don't have to; we
> fixate too much on the general problem and ignore the specifics.
>
> - Dan C.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
@ 2023-03-10 11:51 Noel Chiappa
2023-03-10 14:16 ` Ronald Natalie
0 siblings, 1 reply; 75+ messages in thread
From: Noel Chiappa @ 2023-03-10 11:51 UTC (permalink / raw)
To: tuhs
> From: Warner Losh
> for breaking out of multiple levels of while/for loops.
Yeah, multi-level 'breaks' were one of the things I really missed in C.
The other was BCPL's 'VALOF/RESULTIS'. Back before C compilers got good
enough to do inline substitutions of small procedures (making macros with
arguments less useful), it would have been nice to have, for macros that
wanted to return something. Instead, one had to stand on one's head and use a
'(cond ? ret1 : ret2 )' of some form.
Noel
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 11:51 Noel Chiappa
@ 2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39 ` John Cowan
` (2 more replies)
0 siblings, 3 replies; 75+ messages in thread
From: Ronald Natalie @ 2023-03-10 14:16 UTC (permalink / raw)
To: Noel Chiappa, tuhs
Multilevel breaks are as bad as goto with regard to structure violation.
------ Original Message ------
From "Noel Chiappa" <jnc@mercury.lcs.mit.edu>
To tuhs@tuhs.org
Date 3/10/2023 6:51:45 AM
Subject [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th
anniversary
> > From: Warner Losh
>
> > for breaking out of multiple levels of while/for loops.
>
>Yeah, multi-level 'breaks' were one of the things I really missed in C.
>
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 14:16 ` Ronald Natalie
@ 2023-03-10 14:39 ` John Cowan
2023-03-10 16:30 ` Phil Budne
2023-03-10 17:28 ` Clem Cole
2 siblings, 0 replies; 75+ messages in thread
From: John Cowan @ 2023-03-10 14:39 UTC (permalink / raw)
To: Ronald Natalie; +Cc: Noel Chiappa, tuhs
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Fri, Mar 10, 2023 at 9:16 AM Ronald Natalie <ron@ronnatalie.com> wrote:
Multilevel breaks are as bad as goto with regard to structure violation.
>
No more so than `return` statements in arbitrary places, which nobody
worries about any more.
[-- Attachment #2: Type: text/html, Size: 920 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39 ` John Cowan
@ 2023-03-10 16:30 ` Phil Budne
2023-03-10 17:50 ` Steffen Nurpmeso
2023-03-10 17:28 ` Clem Cole
2 siblings, 1 reply; 75+ messages in thread
From: Phil Budne @ 2023-03-10 16:30 UTC (permalink / raw)
To: tuhs
ron@ronnatalie.com wrote:
> Multilevel breaks are as bad as goto with regard to structure violation.
Back when I was in compilers (so long ago, that it was the DEC PDP-10
FORTRAN compiler(*)) my recall is that break/continue never generated
irreducible flow graphs, as goto can:
https://en.wikipedia.org/wiki/Control-flow_graph#Reducibility
I still remember the days when you could find C code written by PASCAL
programmers, littered with condition variables on loops, and if
statements to not execute the tail of the loop body if the loop
condition was false.
(*) The FORTRAN compiler was written in BLISS-10, which had labeled
statements, and a "leave <label>" construct which was only legal
inside the labeled statement:
http://www.bitsavers.org/pdf/dec/pdp10/TOPS10/DEC-10-LBRMA-A-D_BLISS-10_Programmers_Manual_Ver_4_Feb74.pdf#page=42
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 16:30 ` Phil Budne
@ 2023-03-10 17:50 ` Steffen Nurpmeso
2023-03-10 17:57 ` Paul Winalski
0 siblings, 1 reply; 75+ messages in thread
From: Steffen Nurpmeso @ 2023-03-10 17:50 UTC (permalink / raw)
To: Phil Budne; +Cc: tuhs
Phil Budne wrote in
<202303101630.32AGU2OD008070@ultimate.com>:
|ron@ronnatalie.com wrote:
|> Multilevel breaks are as bad as goto with regard to structure violation.
|
|Back when I was in compilers (so long ago, that it was the DEC PDP-10
|FORTRAN compiler(*)) my recall is that break/continue never generated
|irreducible flow graphs, as goto can:
|
|https://en.wikipedia.org/wiki/Control-flow_graph#Reducibility
|
|I still remember the days when you could find C code written by PASCAL
|programmers,[.]
|littered[.]
I love this.
|with condition variables on loops, and if
|statements to not execute the tail of the loop body if the loop
|condition was false.
|
|(*) The FORTRAN compiler was written in BLISS-10, which had labeled
|statements, and a "leave <label>" construct which was only legal
|inside the labeled statement:
|
|http://www.bitsavers.org/pdf/dec/pdp10/TOPS10/DEC-10-LBRMA-A-D_BLISS-10_\
|Programmers_Manual_Ver_4_Feb74.pdf#page=42
--End of <202303101630.32AGU2OD008070@ultimate.com>
--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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 17:50 ` Steffen Nurpmeso
@ 2023-03-10 17:57 ` Paul Winalski
2023-03-10 18:12 ` Lawrence Stewart
0 siblings, 1 reply; 75+ messages in thread
From: Paul Winalski @ 2023-03-10 17:57 UTC (permalink / raw)
To: Phil Budne, tuhs
> Phil Budne wrote in
> <202303101630.32AGU2OD008070@ultimate.com>:
> |ron@ronnatalie.com wrote:
> |
> |I still remember the days when you could find C code written by PASCAL
> |programmers,[.]
Someone once observed that a skilled FORTRAN programmer could write
FORTRAN in any programming language.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 17:57 ` Paul Winalski
@ 2023-03-10 18:12 ` Lawrence Stewart
0 siblings, 0 replies; 75+ messages in thread
From: Lawrence Stewart @ 2023-03-10 18:12 UTC (permalink / raw)
To: Paul Winalski; +Cc: tuhs
> On Mar 10, 2023, at 12:57 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>
>> Phil Budne wrote in
>> <202303101630.32AGU2OD008070@ultimate.com>:
>> |ron@ronnatalie.com wrote:
>> |
>> |I still remember the days when you could find C code written by PASCAL
>> |programmers,[.]
>
> Someone once observed that a skilled FORTRAN programmer could write
> FORTRAN in any programming language.
>
> -Paul W.
Once taught a programming languages class at Stanford, with assignments in Pascal, APL, LISP, and SNOBOL. The SNOBOL was to solve a crossword by pattern matching, given the grid and the solution words.
One kid had by far the fastest solution, in SNOBOL, but if you held up the listing at arm’s length you would swear it was FORTRAN.
I write my FORTRAN code in C these days.
-L
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39 ` John Cowan
2023-03-10 16:30 ` Phil Budne
@ 2023-03-10 17:28 ` Clem Cole
2023-03-10 17:54 ` Paul Winalski
2 siblings, 1 reply; 75+ messages in thread
From: Clem Cole @ 2023-03-10 17:28 UTC (permalink / raw)
To: Ronald Natalie; +Cc: Noel Chiappa, tuhs
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
On Fri, Mar 10, 2023 at 9:16 AM Ronald Natalie <ron@ronnatalie.com> wrote:
> Multilevel breaks are as bad as goto with regard to structure violation.
>
Amen. My memory of the argument at the time was one of pick your poison.
Each language has trade-offs and it depends on what you value. C was
considered "dirty" by many CS types in the day compared to languages like
Pascal, Simula67, Algol-X.
I've always said the key was what was left out of the language, not what
was put in. Dennis offers a few important pieces of wisdom here:
- "When I read commentary about suggestions for where C should go, I
often think back and give thanks that it wasn't developed under the advice
of a worldwide crowd."
- "A language that doesn't have everything is actually easier to program
in than some that do."
- "C is quirky, flawed, and an enormous success."
Arnold's observation about trying to be small is reasonable,
although contemporaries like BLISS did have support. So the comparison
should really be to BCPL, PL/360, BLISS, *et al*. for features/size
[although Wulf cheated, the BLISS-11 compiler was not self-hosting and
needed a PDP-10 to run it].
ᐧ
[-- Attachment #2: Type: text/html, Size: 2850 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 17:28 ` Clem Cole
@ 2023-03-10 17:54 ` Paul Winalski
0 siblings, 0 replies; 75+ messages in thread
From: Paul Winalski @ 2023-03-10 17:54 UTC (permalink / raw)
To: Clem Cole; +Cc: Noel Chiappa, tuhs
On 3/10/23, Clem Cole <clemc@ccc.com> wrote:
>
> Arnold's observation about trying to be small is reasonable,
> although contemporaries like BLISS did have support. So the comparison
> should really be to BCPL, PL/360, BLISS, *et al*. for features/size
> [although Wulf cheated, the BLISS-11 compiler was not self-hosting and
> needed a PDP-10 to run it].
For what it's worth, BLISS does not have a GOTO expression (BLISS
doesn't have statements per se--everything is an expression and can be
used as a value).
Wulf was studying code optimization. His BLISS-11 compiler, and its
successor at DEC, BLISS-16, implemented many advanced (for the day)
optimizations. In the programming environments at CMU and DEC it was
easier to suffer the mild inconvenience of cross-compilation than to
try to shoehorn the compiler into a 16-bit address space.
It certainly would be possible to implement a native BLISS compiler
for the PDP-11, but you'd have to sacrifice either some of the
optimizations or take a big hit in compilation speed.
-Paul W.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary
@ 2023-03-09 23:01 Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
0 siblings, 1 reply; 75+ messages in thread
From: Steffen Nurpmeso @ 2023-03-09 23:01 UTC (permalink / raw)
To: tuhs
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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:01 [TUHS] " Steffen Nurpmeso
@ 2023-03-09 23:18 ` segaloco via TUHS
2023-03-09 23:21 ` Warner Losh
2023-03-10 1:31 ` Rich Morin
0 siblings, 2 replies; 75+ messages in thread
From: segaloco via TUHS @ 2023-03-09 23:18 UTC (permalink / raw)
To: Steffen Nurpmeso; +Cc: 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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
@ 2023-03-09 23:21 ` Warner Losh
2023-03-09 23:31 ` Luther Johnson
2023-03-10 6:15 ` Dave Horsfall
2023-03-10 1:31 ` Rich Morin
1 sibling, 2 replies; 75+ messages in thread
From: Warner Losh @ 2023-03-09 23:21 UTC (permalink / raw)
To: segaloco; +Cc: The Eunuchs Hysterical Society
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:21 ` Warner Losh
@ 2023-03-09 23:31 ` Luther Johnson
2023-03-09 23:44 ` josh
2023-03-09 23:54 ` Warner Losh
2023-03-10 6:15 ` Dave Horsfall
1 sibling, 2 replies; 75+ messages in thread
From: Luther Johnson @ 2023-03-09 23:31 UTC (permalink / raw)
To: tuhs
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:31 ` Luther Johnson
@ 2023-03-09 23:44 ` josh
2023-03-09 23:54 ` Warner Losh
1 sibling, 0 replies; 75+ messages in thread
From: josh @ 2023-03-09 23:44 UTC (permalink / raw)
To: Luther Johnson; +Cc: tuhs
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:31 ` Luther Johnson
2023-03-09 23:44 ` josh
@ 2023-03-09 23:54 ` Warner Losh
2023-03-10 0:54 ` segaloco via TUHS
1 sibling, 1 reply; 75+ messages in thread
From: Warner Losh @ 2023-03-09 23:54 UTC (permalink / raw)
To: Luther Johnson; +Cc: The Eunuchs Hysterical Society
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:54 ` Warner Losh
@ 2023-03-10 0:54 ` segaloco via TUHS
2023-03-10 1:08 ` Warner Losh
0 siblings, 1 reply; 75+ messages in thread
From: segaloco via TUHS @ 2023-03-10 0:54 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 0:54 ` segaloco via TUHS
@ 2023-03-10 1:08 ` Warner Losh
2023-03-10 10:08 ` Ralph Corderoy
0 siblings, 1 reply; 75+ messages in thread
From: Warner Losh @ 2023-03-10 1:08 UTC (permalink / raw)
To: segaloco; +Cc: The Eunuchs Hysterical Society
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 1:08 ` Warner Losh
@ 2023-03-10 10:08 ` Ralph Corderoy
2023-03-10 11:37 ` arnold
0 siblings, 1 reply; 75+ messages in thread
From: Ralph Corderoy @ 2023-03-10 10:08 UTC (permalink / raw)
To: tuhs
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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 10:08 ` Ralph Corderoy
@ 2023-03-10 11:37 ` arnold
2023-03-10 11:56 ` Ralph Corderoy
0 siblings, 1 reply; 75+ messages in thread
From: arnold @ 2023-03-10 11:37 UTC (permalink / raw)
To: tuhs, ralph
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 11:37 ` arnold
@ 2023-03-10 11:56 ` Ralph Corderoy
2023-03-10 11:59 ` arnold
0 siblings, 1 reply; 75+ messages in thread
From: Ralph Corderoy @ 2023-03-10 11:56 UTC (permalink / raw)
To: tuhs
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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 11:56 ` Ralph Corderoy
@ 2023-03-10 11:59 ` arnold
2023-03-10 12:11 ` Ralph Corderoy
0 siblings, 1 reply; 75+ messages in thread
From: arnold @ 2023-03-10 11:59 UTC (permalink / raw)
To: tuhs, ralph
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 11:59 ` arnold
@ 2023-03-10 12:11 ` Ralph Corderoy
0 siblings, 0 replies; 75+ messages in thread
From: Ralph Corderoy @ 2023-03-10 12:11 UTC (permalink / raw)
To: tuhs
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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:21 ` Warner Losh
2023-03-09 23:31 ` Luther Johnson
@ 2023-03-10 6:15 ` Dave Horsfall
2023-03-10 16:55 ` Steffen Nurpmeso
1 sibling, 1 reply; 75+ messages in thread
From: Dave Horsfall @ 2023-03-10 6:15 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 6:15 ` Dave Horsfall
@ 2023-03-10 16:55 ` Steffen Nurpmeso
2023-03-10 17:02 ` Bakul Shah
2023-03-12 20:47 ` Dave Horsfall
0 siblings, 2 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2023-03-10 16:55 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 16:55 ` Steffen Nurpmeso
@ 2023-03-10 17:02 ` Bakul Shah
2023-03-12 20:47 ` Dave Horsfall
1 sibling, 0 replies; 75+ messages in thread
From: Bakul Shah @ 2023-03-10 17:02 UTC (permalink / raw)
To: Steffen Nurpmeso; +Cc: The Eunuchs Hysterical Society
> 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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-10 16:55 ` Steffen Nurpmeso
2023-03-10 17:02 ` Bakul Shah
@ 2023-03-12 20:47 ` Dave Horsfall
2023-03-12 21:50 ` Warner Losh
1 sibling, 1 reply; 75+ messages in thread
From: Dave Horsfall @ 2023-03-12 20:47 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-12 20:47 ` Dave Horsfall
@ 2023-03-12 21:50 ` Warner Losh
2023-03-12 22:27 ` Steffen Nurpmeso
0 siblings, 1 reply; 75+ messages in thread
From: Warner Losh @ 2023-03-12 21:50 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-12 21:50 ` Warner Losh
@ 2023-03-12 22:27 ` Steffen Nurpmeso
0 siblings, 0 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2023-03-12 22:27 UTC (permalink / raw)
To: Warner Losh, Dave Horsfall; +Cc: The Eunuchs Hysterical Society
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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21 ` Warner Losh
@ 2023-03-10 1:31 ` Rich Morin
1 sibling, 0 replies; 75+ messages in thread
From: Rich Morin @ 2023-03-10 1:31 UTC (permalink / raw)
To: Tautological Eunuch Horticultural Scythians
> 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
^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2023-03-14 21:34 UTC | newest]
Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-10 11:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 11:51 ` [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Ralph Corderoy
2023-03-10 15:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Dan Cross
2023-03-12 7:39 ` Anthony Martin
2023-03-12 11:40 ` Dan Cross
2023-03-12 16:40 ` Paul Winalski
2023-03-13 3:25 ` John Cowan
2023-03-13 10:40 ` Alejandro Colomar (man-pages)
2023-03-13 12:19 ` Dan Cross
2023-03-13 12:43 ` [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Alejandro Colomar
2023-03-13 12:46 ` [TUHS] " Dan Cross
2023-03-13 16:00 ` Paul Winalski
2023-03-13 19:00 ` Clem Cole
2023-03-13 19:09 ` Larry McVoy
2023-03-13 19:17 ` Steve Nickolas
2023-03-13 20:26 ` Dan Cross
2023-03-13 22:25 ` Alejandro Colomar (man-pages)
2023-03-13 19:24 ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
2023-03-13 19:38 ` Luther Johnson
2023-03-14 19:48 ` John Cowan
2023-03-14 19:56 ` Joseph Holsten
2023-03-14 20:01 ` Luther Johnson
2023-03-13 20:48 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
2023-03-13 20:56 ` Bakul Shah
2023-03-14 1:06 ` Larry McVoy
2023-03-13 21:00 ` Paul Winalski
2023-03-13 21:07 ` Bakul Shah
2023-03-13 21:14 ` Dan Cross
2023-03-13 22:15 ` Dave Horsfall
2023-03-13 22:47 ` Dave Horsfall
2023-03-14 0:23 ` Dan Cross
2023-03-14 0:21 ` Dan Cross
2023-03-14 13:52 ` Chet Ramey
2023-03-14 1:27 ` Bakul Shah
2023-03-13 21:28 ` Paul Winalski
2023-03-14 10:04 ` [TUHS] C dialects Ralph Corderoy
2023-03-14 20:02 ` [TUHS] " John Cowan
2023-03-14 21:34 ` Thomas Paulsen
2023-03-14 0:38 ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) John Cowan
2023-03-14 2:49 ` Theodore Ts'o
2023-03-14 3:06 ` G. Branden Robinson
-- strict thread matches above, loose matches on Subject: below --
2023-03-10 15:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2023-03-10 19:04 ` Dan Cross
2023-03-10 19:35 ` segaloco via TUHS
2023-03-10 11:51 Noel Chiappa
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39 ` John Cowan
2023-03-10 16:30 ` Phil Budne
2023-03-10 17:50 ` Steffen Nurpmeso
2023-03-10 17:57 ` Paul Winalski
2023-03-10 18:12 ` Lawrence Stewart
2023-03-10 17:28 ` Clem Cole
2023-03-10 17:54 ` Paul Winalski
2023-03-09 23:01 [TUHS] " Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21 ` Warner Losh
2023-03-09 23:31 ` Luther Johnson
2023-03-09 23:44 ` josh
2023-03-09 23:54 ` Warner Losh
2023-03-10 0:54 ` segaloco via TUHS
2023-03-10 1:08 ` Warner Losh
2023-03-10 10:08 ` Ralph Corderoy
2023-03-10 11:37 ` arnold
2023-03-10 11:56 ` Ralph Corderoy
2023-03-10 11:59 ` arnold
2023-03-10 12:11 ` Ralph Corderoy
2023-03-10 6:15 ` Dave Horsfall
2023-03-10 16:55 ` Steffen Nurpmeso
2023-03-10 17:02 ` Bakul Shah
2023-03-12 20:47 ` Dave Horsfall
2023-03-12 21:50 ` Warner Losh
2023-03-12 22:27 ` Steffen Nurpmeso
2023-03-10 1:31 ` Rich Morin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).