On 31 Jan 2024 09:54:15 GMT, Bob Eager wrote:

> We had a machine that ran FORTRAN for the physics department. One guy
> had a program that crashed the machine. As in, the microcode halted.
> That was an array bounds error.
>
> Full story:
>
> http://www.bobeager.uk/anecdotes.html#hwhack

We contacted ICL, but we never seemed to reach anyone who either
understood what the problem was, or had the power or inclination
to get it fixed ...

If this was not after the Fujitsu acquisition, I assume it wasn’t long
before ...

On Wed, 31 Jan 2024 11:05:22 -0500, Stephen Hoffman wrote:

> (Not that I prefer to have to implement manual cleanup, much as I'd like
> to avoid explicitly deallocating memory in C.

Note that free(3) is defined as idempotent; freeing a NULL pointer is a
harmless no-op. That simplifies things a lot.

On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:

> For the not VB.NET knowledgable:
>
> Using o1 As New X("A")
> ...
> End Using
>
> calls o1.Dispose() when the block is exited no matter how it is exited -
> normal or exception does not matter Dispose is always called.

Python has “context managers” which are a generalization of this. It also
has “try/finally” blocks, which are good for one-off cases.

On Wed, 31 Jan 2024 15:52:30 +0200, Michael S wrote:

> One option is named construct and named break.

I have never written a goto in C code (not production code, anyway). These
days, you need to do so much dynamic allocation, there is nearly always
some need for cleanup when exiting an inner block anyway, so you can’t
just jump directly somewhere else first. The overall pattern looks like
this:

MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);

You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.

On Wed, 31 Jan 2024 21:21:10 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On 31 Jan 2024 09:54:15 GMT, Bob Eager wrote:
>
> > We had a machine that ran FORTRAN for the physics department. One
> > guy had a program that crashed the machine. As in, the microcode
> > halted. That was an array bounds error.
> >
> > Full story:
> >
> > http://www.bobeager.uk/anecdotes.html#hwhack
>
> We contacted ICL, but we never seemed to reach anyone who either
> understood what the problem was, or had the power or inclination
> to get it fixed ...
>
> If this was not after the Fujitsu acquisition, I assume it wasn’t
> long before ...

From the article it looks like 1980, probably H1.

On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
> I have never written a goto in C code (not production code, anyway). These
> days, you need to do so much dynamic allocation, there is nearly always
> some need for cleanup when exiting an inner block anyway, so you can’t
> just jump directly somewhere else first. The overall pattern looks like
> this:
>
> MyPtr obj = NULL;
> do /*once*/
> {
> ... possible other stuff ...
> «allocate memory for obj»;
> if («error occurred»)
> break;
> ... possible other stuff using obj ...
> }
> while (false);
> free(obj);
>
> You can confirm, just by inspection, that there is no path out of the
> block that does not pass through the free() call precisely once.

And the difference compared to:

MyPtr obj = NULL;
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
goto lbl_freeobj;
... possible other stuff using obj ...
lbl_freeobj:
free(obj);

are?

Arne

On 1/31/2024 4:24 PM, Lawrence D'Oliveiro wrote:
> On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
>> For the not VB.NET knowledgable:
>>
>> Using o1 As New X("A")
>> ...
>> End Using
>>
>> calls o1.Dispose() when the block is exited no matter how it is exited -
>> normal or exception does not matter Dispose is always called.
>
> Python has “context managers” which are a generalization of this. It also
> has “try/finally” blocks, which are good for one-off cases.

C# was born with using (2002), Python got with in 2.5 (2006)
and Java got try with resource in 1.7 (2011).

MS got a good idea and the rest copied it.

Arne

On 1/31/2024 5:08 PM, Arne Vajhøj wrote:
> On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
>> I have never written a goto in C code (not production code, anyway). These
>> days, you need to do so much dynamic allocation, there is nearly always
>> some need for cleanup when exiting an inner block anyway, so you can’t
>> just jump directly somewhere else first. The overall pattern looks like
>> this:
>>
>> MyPtr obj = NULL;
>> do /*once*/
>> {
>> ... possible other stuff ...
>> «allocate memory for obj»;
>> if («error occurred»)
>> break;
>> ... possible other stuff using obj ...
>> }
>> while (false);
>> free(obj);
>>
>> You can confirm, just by inspection, that there is no path out of the
>> block that does not pass through the free() call precisely once.
>
> And the difference compared to:
>
> MyPtr obj = NULL;
> ... possible other stuff ...
> «allocate memory for obj»;
> if («error occurred»)
> goto lbl_freeobj;
> ... possible other stuff using obj ...
> lbl_freeobj:
> free(obj);
>
> are?
>
> Arne
>
>

I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
My question is, why? If the need is a simple and rather easy to understand
branch, why get complex, just to be "political correct", which ia also a rather
stupid concept.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wed, 31 Jan 2024 17:13:26 -0500, Arne Vajhøj wrote:

> On 1/31/2024 4:24 PM, Lawrence D'Oliveiro wrote:
>
>> On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
>>
>>> For the not VB.NET knowledgable:
>>>
>>> Using o1 As New X("A")
>>> ...
>>> End Using
>>>
>>> calls o1.Dispose() when the block is exited no matter how it is exited -
>>> normal or exception does not matter Dispose is always called.
>>
>> Python has “context managers” which are a generalization of this. It also
>> has “try/finally” blocks, which are good for one-off cases.
>
> C# was born with using (2002), Python got with in 2.5 (2006)
> and Java got try with resource in 1.7 (2011).
>
> MS got a good idea and the rest copied it.

That is also true of async/await. But note that Python is the only one
of the three that tries to use reference-counting as an alternative to
garbage collection.

And now it looks like C# might be shuffling off into those retirement
pastures
<https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/>.

On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:

> On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
>
>> I have never written a goto in C code (not production code, anyway). These
>> days, you need to do so much dynamic allocation, there is nearly always
>> some need for cleanup when exiting an inner block anyway, so you can’t
>> just jump directly somewhere else first. The overall pattern looks like
>> this:
>>
>> MyPtr obj = NULL;
>> do /*once*/
>> {
>> ... possible other stuff ...
>> «allocate memory for obj»;
>> if («error occurred»)
>> break;
>> ... possible other stuff using obj ...
>> }
>> while (false);
>> free(obj);
>>
>> You can confirm, just by inspection, that there is no path out of the
>> block that does not pass through the free() call precisely once.
>
> And the difference compared to:
>
> MyPtr obj = NULL;
> ... possible other stuff ...
> «allocate memory for obj»;
> if («error occurred»)
> goto lbl_freeobj;
> ... possible other stuff using obj ...
> lbl_freeobj:
> free(obj);
>
> are?

Nesting. Try to scale up to something like

static PyObject * discipline_makedict
(
PyObject * self,
PyObject * args
)
{
PyObject * result = NULL;
PyObject * tempresult = NULL;
br_PyObject * items;
const br_char * msg = NULL;
do /*once*/
{
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (not parsed_ok)
break;
fprintf(stdout, "makedict says: “%s”\n", msg);
if (not PyTuple_Check(items))
{
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
break;
} /*if*/
const ssize_t nr_items = PyTuple_Size(items);
if (PyErr_Occurred())
break;
tempresult = PyDict_New();
if (tempresult == NULL)
break;
for (ssize_t i = 0;;)
{
if (i == nr_items)
break;
br_PyObject * const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
{
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
} /*if*/
br_PyObject * const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
br_PyObject * const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type or second == (PyObject *)&ExceptMe_type)
{
PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
break;
} /*if*/
if (PyDict_SetItem(tempresult, first, second) < 0)
break;
++i;
} /*for*/
if (PyErr_Occurred())
break;
/* all done */
result = tempresult;
tempresult = NULL; /* so I don’t dispose of it yet */
}
while (false);
Py_XDECREF(tempresult);
return
result;
} /*discipline_makedict*/

More details here
<https://gitlab.com/ldo/a_structured_discipline_of_programming/>.

On 31/01/2024 18:27, Dave Froble wrote:
> On 1/31/2024 7:03 AM, Chris Townley wrote:
>> On 31/01/2024 04:28, Dave Froble wrote:
>>> On 1/30/2024 9:40 AM, Chris Townley wrote:
>>>> On 30/01/2024 07:06, Dave Froble wrote:
>>>>> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>>>>>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>>>>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne@vajhoej.dk> wrote:
>>>>>>>> The code is VB6.
>>>>>>>>
>>>>>>>> But none of the problems are Basic specific. It is possible
>>>>>>>> to write the same bad code in C or Fortran or whatever.
>>>>>>>>
>>>>>>>> So it just shows that there are some really really bad
>>>>>>>> programmers out
>>>>>>>> there.
>>>>>>>
>>>>>>> I have worked with people who could write spaghetti Fortran in any
>>>>>>> programming language available.
>>>>>>
>>>>>> "A real Fortran programmer can write Fortran in any language"
>>>>>>
>>>>>> Every time this comes up I post this Fortran/Pascal code:
>>>>>>
>>>>>>       PROGRAM GOTOFUN(INPUT,OUTPUT);
>>>>>>       LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>>>>>       VAR LBL:INTEGER;
>>>>>>       VAR I:INTEGER;
>>>>>>       BEGIN
>>>>>> L731: GOTO L113;
>>>>>>       LBL:=399;
>>>>>> L113: I:=0;
>>>>>>       WRITELN(I);
>>>>>> L247: LBL:=601;
>>>>>>       IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO
>>>>>> L399;
>>>>>> L588: I:=I+1;
>>>>>>       WRITELN(I);
>>>>>>       GOTO L399;
>>>>>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>>>>>> L922: I:=I+1;
>>>>>>       WRITELN(I);
>>>>>>       CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>>>>>> L399: GOTO L761;
>>>>>> L601: END.
>>>>>>
>>>>>> :-)
>>>>>>
>>>>>> Arne
>>>>>>
>>>>>
>>>>> I'm amused every time the GoTo bashing begins.
>>>>>
>>>>> Not only is there nothing wrong when using a branch operation, when
>>>>> appropriate, just look at the assembler listings after
>>>>> compilation.  Branching
>>>>> is just about all assembler does, as required.
>>>>>
>>>>> Now, I won't defend what I and most consider improper use of the poor
>>>>> misunderstood GoTo statement.
>>>>>
>>>>
>>>> But unless used very carefully, it can create horrible spaghetti
>>>> like code, and
>>>> is also easy to screw up.
>>>>
>>>> Using proper structured constructs is much better - easier to read
>>>> as well,
>>>> hence better maintainability.
>>>>
>>>>
>>>
>>> Prey tell, what structured construct will perform cleanup and exit?
>>> I always
>>> expected a return from routines and such.
>>>
>>
>> It would depend on what is needing to be done
>>
>
> Final cleanup, if required, and exit the program.
>
> Knew a guy that would us a gosub to go to the END statement.  Drove me
> nuts.
>

We always used global error handling, as well as local when error...

At least with DEC Basic, it always handled garbage collection

--
Chris

On 1/31/2024 6:21 PM, Lawrence D'Oliveiro wrote:
> On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
>
>> On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
>>
>>> I have never written a goto in C code (not production code, anyway). These
>>> days, you need to do so much dynamic allocation, there is nearly always
>>> some need for cleanup when exiting an inner block anyway, so you can’t
>>> just jump directly somewhere else first. The overall pattern looks like
>>> this:
>>>
>>> MyPtr obj = NULL;
>>> do /*once*/
>>> {
>>> ... possible other stuff ...
>>> «allocate memory for obj»;
>>> if («error occurred»)
>>> break;
>>> ... possible other stuff using obj ...
>>> }
>>> while (false);
>>> free(obj);
>>>
>>> You can confirm, just by inspection, that there is no path out of the
>>> block that does not pass through the free() call precisely once.
>>
>> And the difference compared to:
>>
>> MyPtr obj = NULL;
>> ... possible other stuff ...
>> «allocate memory for obj»;
>> if («error occurred»)
>> goto lbl_freeobj;
>> ... possible other stuff using obj ...
>> lbl_freeobj:
>> free(obj);
>>
>> are?
>
> Nesting.

Goto work fine with nested loops. In fact it is one of the cases
where it really makes sense.

> Try to scale up to something like
>
> static PyObject * discipline_makedict
> (
> PyObject * self,
> PyObject * args
> )
> {
> PyObject * result = NULL;
> PyObject * tempresult = NULL;
> br_PyObject * items;
> const br_char * msg = NULL;
> do /*once*/
> {
> const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
> if (not parsed_ok)
> break;
> fprintf(stdout, "makedict says: “%s”\n", msg);
> if (not PyTuple_Check(items))
> {
> PyErr_SetString(PyExc_TypeError, "expecting a tuple");
> break;
> } /*if*/
> const ssize_t nr_items = PyTuple_Size(items);
> if (PyErr_Occurred())
> break;
> tempresult = PyDict_New();
> if (tempresult == NULL)
> break;
> for (ssize_t i = 0;;)
> {
> if (i == nr_items)
> break;
> br_PyObject * const item = PyTuple_GetItem(items, i);
> if (item == NULL)
> break;
> if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
> {
> PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
> break;
> } /*if*/
> br_PyObject * const first = PyTuple_GetItem(item, 0);
> if (first == NULL)
> break;
> br_PyObject * const second = PyTuple_GetItem(item, 1);
> if (second == NULL)
> break;
> if (first == (PyObject *)&ExceptMe_type or second == (PyObject *)&ExceptMe_type)
> {
> PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
> break;
> } /*if*/
> if (PyDict_SetItem(tempresult, first, second) < 0)
> break;
> ++i;
> } /*for*/
> if (PyErr_Occurred())
> break;
> /* all done */
> result = tempresult;
> tempresult = NULL; /* so I don’t dispose of it yet */
> }
> while (false);
> Py_XDECREF(tempresult);
> return
> result;
> } /*discipline_makedict*/

That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.

A well named goto label is much more informative than a plain break.

> More details here
> <https://gitlab.com/ldo/a_structured_discipline_of_programming/>.

Truly bad design.

All the code examples would look better with the do while(false) loops
removed and appropriate goto's.

Arne

On 1/31/2024 6:18 PM, Lawrence D'Oliveiro wrote:
> On Wed, 31 Jan 2024 17:13:26 -0500, Arne Vajhøj wrote:
>
>> On 1/31/2024 4:24 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
>>>
>>>> For the not VB.NET knowledgable:
>>>>
>>>> Using o1 As New X("A")
>>>> ...
>>>> End Using
>>>>
>>>> calls o1.Dispose() when the block is exited no matter how it is exited -
>>>> normal or exception does not matter Dispose is always called.
>>>
>>> Python has “context managers” which are a generalization of this. It also
>>> has “try/finally” blocks, which are good for one-off cases.
>>
>> C# was born with using (2002), Python got with in 2.5 (2006)
>> and Java got try with resource in 1.7 (2011).
>>
>> MS got a good idea and the rest copied it.
>
> That is also true of async/await. But note that Python is the only one
> of the three that tries to use reference-counting as an alternative to
> garbage collection.

All of them use garbage collection.

Java and C# use tracing garbage collection.

Python use both tracing garbage collection and reference
counting garbage collection. Or more precisely the common
implementation CPython does - there are other Python
implementations that use only tracing garbage collection.

> And now it looks like C# might be shuffling off into those retirement
> pastures
> <https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/>.

Very interesting for Rust, but not particular important for C#.

C# is primarily for business applications.

That Microsoft will rewrite some platform software supporting
moving data within Office 365 in Azure from C# to Rust does
not indicate the end of C#.

I would consider it more negative for Go. Go is big in that
type of cloud and/or container platform software, so MS not
picking Go may indicate something.

Arne

In article <upejl0$1nkl5$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
> My question is, why? If the need is a simple and rather easy to understand
>branch, why get complex,

`goto` by itself is a sharp tool; sometimes incredibly useful,
but dangerous if misused. Our industry is littered with example
after example of `goto` misused. For instance,
https://dwheeler.com/essays/apple-goto-fail.html

Because of the potential and history of misuse, it's a laudable
goal to reduce use of `goto`, and indeed, over the years we've
seen generations of languages where the primary use cases have
been analyzed and the most useful lifted into new constructs
that become first-class parts of their respective languages;
`break` and `continue` for loops, exceptions, and so on.

Moreover, this is useful in the sense that programming languages
also serve a communicative purpose. How many of us would change
a `for` loop to if's and gotos given the choice? I wager few
would; the former communicates intent far more clearly than the
latter. For that matter, if we could iterate over a collection,
that's even better again.

That said, `goto` obviously _does_ have a place when used
judiciously. As Ken Thompson once said, "if you want to go
somewhere, goto is the best way to get there." Like all goals,
the desire to reduce `goto` prevelence is mostly aspirational.
Certainly, we're well past the context of Djikstra's "GO TO
STATEMENT CONSIDERED HARMFUL" CACM letter.

- Dan C.

In article <upeokq$1o97f$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/31/2024 6:21 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
>>> On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
>>[snip]
>> Nesting.
>
>Goto work fine with nested loops. In fact it is one of the cases
>where it really makes sense.

I think the troll was referring to nested control structures,
with nested resource handling.

>> Try to scale up to something like
>>
>> static PyObject * discipline_makedict
>> (
>> PyObject * self,
>> PyObject * args
>> )
>> {
>> PyObject * result = NULL;
>> PyObject * tempresult = NULL;
>> br_PyObject * items;
>> const br_char * msg = NULL;
>> do /*once*/
>> {
>> const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
>> if (not parsed_ok)
>> break;
>> fprintf(stdout, "makedict says: “%s”\n", msg);
>> if (not PyTuple_Check(items))
>> {
>> PyErr_SetString(PyExc_TypeError, "expecting a tuple");
>> break;
>> } /*if*/
>> const ssize_t nr_items = PyTuple_Size(items);
>> if (PyErr_Occurred())
>> break;
>> tempresult = PyDict_New();
>> if (tempresult == NULL)
>> break;
>> for (ssize_t i = 0;;)
>> {
>> if (i == nr_items)
>> break;
>> br_PyObject * const item = PyTuple_GetItem(items, i);
>> if (item == NULL)
>> break;
>> if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
>> {
>> PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
>> break;
>> } /*if*/
>> br_PyObject * const first = PyTuple_GetItem(item, 0);
>> if (first == NULL)
>> break;
>> br_PyObject * const second = PyTuple_GetItem(item, 1);
>> if (second == NULL)
>> break;
>> if (first == (PyObject *)&ExceptMe_type or second == (PyObject *)&ExceptMe_type)
>> {
>> PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
>> break;
>> } /*if*/
>> if (PyDict_SetItem(tempresult, first, second) < 0)
>> break;
>> ++i;
>> } /*for*/
>> if (PyErr_Occurred())
>> break;
>> /* all done */
>> result = tempresult;
>> tempresult = NULL; /* so I don’t dispose of it yet */
>> }
>> while (false);
>> Py_XDECREF(tempresult);
>> return
>> result;
>> } /*discipline_makedict*/
>
>That code would look a lot cleaner if the do while(false) loop got
>removed and the relevant breaks got replaced by goto's.

I almost agree. That could is borderline unreadable, but if one
detangles it from the weird web of style its obfuscated by, one
realizes it can be written in a far more straight-forward manner
without either `goto` or the weird do/while style. Near as I
can tell, the following rough cut is equivalent to the original:

static PyObject *
discipline_makedict(PyObject *self, PyObject *args)
{ br_PyObject *items;
const br_char *msg = NULL;

const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (!parsed_ok)
return NULL;

printf("makedict says: \xe2\x80\x9c%s\xe2\x80\x9d\n", msg);
if (!PyTuple_Check(items)) {
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
return NULL;
}
const ssize_t nitems = PyTuple_Size(items);
if (PyErr_Occurred())
return NULL;

PyObject *result = PyDict_New();
if (result == NULL)
return NULL;

for (ssize_t i = 0; i < nitems; ++i) {
br_PyObject *const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (!PyTuple_Check(item) || PyTuple_Size(item) != 2) {
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
}
br_PyObject *const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
br_PyObject *const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type || second == (PyObject *)&ExceptMe_type) {
PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
break;
}
if (PyDict_SetItem(result, first, second) < 0)
break;
}

if (PyErr_Occurred()) {
Py_XDECREF(result);
return NULL;
}

return result;
}

I would argue this is more idiomatic, shorter, simpler, easier
to both read and to reason about, and uses fewer variables.

I couldn't really figure out why the `printf` was in there, so I
left it in; it looks like debugging code though. I didn't test
it, however, since I don't really care.

>A well named goto label is much more informative than a plain break.

Agreed. In this case, the breaks are sufficiently contained
once the rest of the cruft is cut away that I don't think a goto
is any better.

>> More details here
>> <https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
>
>Truly bad design.
>
>All the code examples would look better with the do while(false) loops
>removed and appropriate goto's.

Agreed. That code is straight garbage, and should not make it
past any serious review.

- Dan C.

On Wed, 31 Jan 2024 19:29:14 -0500, Arne Vajhøj wrote:

> That code would look a lot cleaner if the do while(false) loop got
> removed and the relevant breaks got replaced by goto's.

Show us how you would do it. I can take you through my code step by step,
block by block, if that will help.

On Wed, 31 Jan 2024 19:42:50 -0500, Arne Vajhøj wrote:

> C# is primarily for business applications.

Never heard of it being used for anything important. For example,
Microsoft would never use it itself in Office.

On 1/31/2024 8:26 PM, Dan Cross wrote:
> In article <upejl0$1nkl5$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
>> My question is, why? If the need is a simple and rather easy to understand
>> branch, why get complex,
>
> `goto` by itself is a sharp tool; sometimes incredibly useful,
> but dangerous if misused. Our industry is littered with example
> after example of `goto` misused. For instance,
> https://dwheeler.com/essays/apple-goto-fail.html

Cars are dangerous, should we go back to horses?
Horses are dangerous, should we go back to walking?
Walking is dangerous ...

Flying is dangerous ...
Boats are dangerous ...

Crossing the street is dangerous. But we're taught to look before stepping in
front of the bus.

GoTo can be dangerous ...
Learn good programming habits ...

>
> That said, `goto` obviously _does_ have a place when used
> judiciously.

Yes, that ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/31/2024 7:29 PM, Arne Vajhøj wrote:
> On 1/31/2024 6:21 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
>>
>>> On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> I have never written a goto in C code (not production code, anyway). These
>>>> days, you need to do so much dynamic allocation, there is nearly always
>>>> some need for cleanup when exiting an inner block anyway, so you can’t
>>>> just jump directly somewhere else first. The overall pattern looks like
>>>> this:
>>>>
>>>> MyPtr obj = NULL;
>>>> do /*once*/
>>>> {
>>>> ... possible other stuff ...
>>>> «allocate memory for obj»;
>>>> if («error occurred»)
>>>> break;
>>>> ... possible other stuff using obj ...
>>>> }
>>>> while (false);
>>>> free(obj);
>>>>
>>>> You can confirm, just by inspection, that there is no path out of the
>>>> block that does not pass through the free() call precisely once.
>>>
>>> And the difference compared to:
>>>
>>> MyPtr obj = NULL;
>>> ... possible other stuff ...
>>> «allocate memory for obj»;
>>> if («error occurred»)
>>> goto lbl_freeobj;
>>> ... possible other stuff using obj ...
>>> lbl_freeobj:
>>> free(obj);
>>>
>>> are?
>>
>> Nesting.
>
> Goto work fine with nested loops. In fact it is one of the cases
> where it really makes sense.
>
>> Try to scale up to something like
>>
>> static PyObject * discipline_makedict
>> (
>> PyObject * self,
>> PyObject * args
>> )
>> {
>> PyObject * result = NULL;
>> PyObject * tempresult = NULL;
>> br_PyObject * items;
>> const br_char * msg = NULL;
>> do /*once*/
>> {
>> const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
>> if (not parsed_ok)
>> break;
>> fprintf(stdout, "makedict says: “%s”\n", msg);
>> if (not PyTuple_Check(items))
>> {
>> PyErr_SetString(PyExc_TypeError, "expecting a tuple");
>> break;
>> } /*if*/
>> const ssize_t nr_items = PyTuple_Size(items);
>> if (PyErr_Occurred())
>> break;
>> tempresult = PyDict_New();
>> if (tempresult == NULL)
>> break;
>> for (ssize_t i = 0;;)
>> {
>> if (i == nr_items)
>> break;
>> br_PyObject * const item = PyTuple_GetItem(items, i);
>> if (item == NULL)
>> break;
>> if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
>> {
>> PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
>> break;
>> } /*if*/
>> br_PyObject * const first = PyTuple_GetItem(item, 0);
>> if (first == NULL)
>> break;
>> br_PyObject * const second = PyTuple_GetItem(item, 1);
>> if (second == NULL)
>> break;
>> if (first == (PyObject *)&ExceptMe_type or second == (PyObject
>> *)&ExceptMe_type)
>> {
>> PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
>> break;
>> } /*if*/
>> if (PyDict_SetItem(tempresult, first, second) < 0)
>> break;
>> ++i;
>> } /*for*/
>> if (PyErr_Occurred())
>> break;
>> /* all done */
>> result = tempresult;
>> tempresult = NULL; /* so I don’t dispose of it yet */
>> }
>> while (false);
>> Py_XDECREF(tempresult);
>> return
>> result;
>> } /*discipline_makedict*/
>
> That code would look a lot cleaner if the do while(false) loop got
> removed and the relevant breaks got replaced by goto's.
>
> A well named goto label is much more informative than a plain break.
>
>> More details here
>> <https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
>
> Truly bad design.
>
> All the code examples would look better with the do while(false) loops
> removed and appropriate goto's.
>
> Arne
>

It's called do whatever to avoid a goto, and it can be very bad ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wed, 2024-01-31 at 22:57 -0500, Dave Froble wrote:
>
> GoTo can be dangerous ...
> Learn good programming habits ...

Linux uses goto in the kernel a lot. Should I throw it in the bin?
--
Tactical Nuclear Kittens

In article <upf4q6$1tp4r$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/31/2024 8:26 PM, Dan Cross wrote:
>> In article <upejl0$1nkl5$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
>>> My question is, why? If the need is a simple and rather easy to understand
>>> branch, why get complex,
>>
>> `goto` by itself is a sharp tool; sometimes incredibly useful,
>> but dangerous if misused. Our industry is littered with example
>> after example of `goto` misused. For instance,
>> https://dwheeler.com/essays/apple-goto-fail.html
>
>Cars are dangerous, should we go back to horses?

I think the analogy is more like, "cars are dangerous, so should
we get rid of seatbelts?" Or, "Takata made dangerous air bags,
so what's the point of having them at all?"

>Horses are dangerous, should we go back to walking?
>Walking is dangerous ...
>
>Flying is dangerous ...
>Boats are dangerous ...
>
>Crossing the street is dangerous. But we're taught to look before stepping in
>front of the bus.
>
>GoTo can be dangerous ...
>Learn good programming habits ...

I wonder if you read the rest of my post which tried, perhaps
imperfectly, to say more or less the same thing.

>> That said, `goto` obviously _does_ have a place when used
>> judiciously.
>
>Yes, that ...

Just so.

- Dan C.

In article <3c16a3a0f6100e01b49cf3de3d3411f051b23cab.camel@munted.eu>,
Single Stage to Orbit <alex.buell@munted.eu> wrote:
>On Wed, 2024-01-31 at 22:57 -0500, Dave Froble wrote:
>>
>> GoTo can be dangerous ...
>> Learn good programming habits ...
>
>Linux uses goto in the kernel a lot. Should I throw it in the bin?

I see the point has gone over multiple people's heads, which
probably means I did a poor job explaining. Like I said, `goto`
*can* be useful. Does that mean we should use it in lieu of
structued constructs like loops, when available? No.

It's silly to deny that `goto` has been abused, leading to lots
of very poor code. This is and was well-known. Rising to the
defense of `goto` without acknowledging its faults is similarly
silly.

- Dan C.

In article <upf0r9$1t7cn$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Wed, 31 Jan 2024 19:29:14 -0500, Arne Vajhøj wrote:
>
>> That code would look a lot cleaner if the do while(false) loop got
>> removed and the relevant breaks got replaced by goto's.
>
>Show us how you would do it. I can take you through my code step by step,
>block by block, if that will help.

As I posted in my other message (untested):

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include <stdio.h>

static PyObject *
discipline_makedict(PyObject *self, PyObject *args)
{ PyObject *items;
const char *msg = NULL;

const int parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (!parsed_ok)
return NULL;

printf("makedict says: \xe2\x80\x9c%s\xe2\x80\x9d\n", msg);
if (!PyTuple_Check(items)) {
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
return NULL;
}
const ssize_t nitems = PyTuple_Size(items);
if (PyErr_Occurred())
return NULL;

PyObject *result = PyDict_New();
if (result == NULL)
return NULL;

for (ssize_t i = 0; i < nitems; ++i) {
PyObject *const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (!PyTuple_Check(item) || PyTuple_Size(item) != 2) {
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
}
PyObject *const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
PyObject *const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type || second == (PyObject *)&ExceptMe_type) {
PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
break;
}
if (PyDict_SetItem(result, first, second) < 0)
break;
}

if (PyErr_Occurred()) {
Py_XDECREF(result);
}

return result;
}

No gotos, no simulated goto-via-early-break in a do/while(false)
loop.

As I said previously, this is more idiomatic, simpler, easier to
reason about, easier to read, and uses fewer variables. Your
initial code was, to be blunt, unreadable and truly awful shit.

- Dan C.

On 2024-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
> I would argue this is more idiomatic, shorter, simpler, easier
> to both read and to reason about, and uses fewer variables.
>

I agree and this is the general style I use, but with one difference.
In my code, I always, always, use braces in an if() statement, even
if the conditional code is only a single statement. For example:

const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (!parsed_ok)
{
return NULL;
}

I think that makes it more clear and removes any possibility of future
code changes accidentally not adding the braces at that time.

[And yes, about the above indentation, Simon _is_ indeed a Whitesmiths
person. :-)]

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/31/2024 8:26 PM, Dan Cross wrote:
>> In article <upejl0$1nkl5$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
>>> My question is, why? If the need is a simple and rather easy to understand
>>> branch, why get complex,
>>
>> `goto` by itself is a sharp tool; sometimes incredibly useful,
>> but dangerous if misused. Our industry is littered with example
>> after example of `goto` misused. For instance,
>> https://dwheeler.com/essays/apple-goto-fail.html
>
> Cars are dangerous, should we go back to horses?

No, but we introduced safety measures based on experience.

> Horses are dangerous, should we go back to walking?

No, but we introduced safety measures based on experience.

> Walking is dangerous ...

We introduced safety measures based on experience (depending on
the type of walking you are doing).

>
> Flying is dangerous ...

We introduced safety measures based on experience.

> Boats are dangerous ...

We introduced safety measures based on experience.

>
> GoTo can be dangerous ...
> Learn good programming habits ...
>

We introduced safer alternatives based on experience.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.