In article <upg5s6$2346b$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>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.

That's fine. Indeed, many modern languages mandate braces in
around the bodies of conditionals and loops as part of the base
syntax of the language (Go and Rust both do). I didn't bother
because I only made the minimal changes to that crank's code.

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

From, Henry Spencer's, "The Ten Commandments for C Programmers":

|8. Thou shalt make thy program's purpose and structure clear to
|thy fellow man by using the One True Brace Style, even if thou
|likest it not, for thy creativity is better used in solving
|problems than in creating beautiful new impediments to
|understanding.

It is somewhat odd to me how contentious this is after so many
years, but I kind of get how attached one can be to a particular
code style. When I worked at Google, I thought the mandated
style for C++ code was hideously ugly; after a few weeks, I
stopped noticing. When `clang-format` came along, it was great
because it essentially eliminated all of the stupid style things
from reviews. Go and Rust (and other modern languages)
effectively ended this as an issue by shipping with code
formatters and making people use them.

The bottom line for me, for C/C++ code, is that I don't care
what style one uses, as long as one is consistent; it is
shocking the extent to which divergent styles within a code base
can increase cognitive load.

- Dan C.

On 2/1/2024 8:21 AM, Simon Clubley wrote:
> 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.

That is a common coding convention.

Including the original SUN Java coding convention from 1999.

Arne

On Thu, 1 Feb 2024 18:40:00 -0500, Arne Vajhøj wrote:

>> const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
>> if (!parsed_ok)
>> {
>> return NULL;
>> }
>>
> That is a common coding convention.

How do you handle nesting? Remember this part?

if (PyDict_SetItem(tempresult, first, second) < 0)
break;

If you did a return instead at that point, it would leak memory.

Note also the handover of ownership after all successful allocations, at
the end of the block:

} /*for*/
if (PyErr_Occurred())
break;
/* all done */
result = tempresult;
tempresult = NULL; /* so I don’t dispose of it yet */

This way, the cleanup at the end does not need to distinguish between
success and failure returns:

Py_XDECREF(tempresult);
return
result;

=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>On 1/31/2024 11:17 AM, Scott Dorsey wrote:
>> Michael S <already5chosen@yahoo.com> wrote:
>>>
>>> The third option, the one I like least (an understatement) is use of
>>> exceptions. Despite my personal preferences, it's quite popular.
>>
>> Exceptions can be very elegant or very inelegant... and it is entirely
>> possible to have an exception that doesn't clean anything up at all and
>> just exits and lets the operating system deal with the memory. On many
>> systems this is a great idea because being able to exit quickly on a failure
>> is more important than people give it credit for. On some other systems
>> that have memory management issues it can lead to leakage.
>
>It is probably a bit easier to implement exceptions in languages
>with garbage collection and a lot easier for developers to avoid
>memory leak bugs.

True, but "dispose of all memory belonging to this process" should not be
a big deal on a demand-paged machine. There are some architectures where
it can be, though.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/1/2024 8:44 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>> On 1/31/2024 11:17 AM, Scott Dorsey wrote:
>>> Michael S <already5chosen@yahoo.com> wrote:
>>>> The third option, the one I like least (an understatement) is use of
>>>> exceptions. Despite my personal preferences, it's quite popular.
>>>
>>> Exceptions can be very elegant or very inelegant... and it is entirely
>>> possible to have an exception that doesn't clean anything up at all and
>>> just exits and lets the operating system deal with the memory. On many
>>> systems this is a great idea because being able to exit quickly on a failure
>>> is more important than people give it credit for. On some other systems
>>> that have memory management issues it can lead to leakage.
>>
>> It is probably a bit easier to implement exceptions in languages
>> with garbage collection and a lot easier for developers to avoid
>> memory leak bugs.
>
> True, but "dispose of all memory belonging to this process" should not be
> a big deal on a demand-paged machine. There are some architectures where
> it can be, though.

The issue is not if the process goes away but if the process
continue after execution flow has dropped back a number of levels
on the call stack.

The C++ code I posted did exit, but main could have called
f1 again after catching the exception. Maybe doing it
a billion times leaking one object for every call.

Arne

On 2/1/2024 3:43 AM, Single Stage to Orbit 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?
>

Pitch it because it's Linux, not because of the goto

:-)

--
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 9:49 PM, Lawrence D'Oliveiro 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.

It is pretty simple.

do {
allocate(o1);
...
if(...) break;
...
} while(false);
deallocate(o1);

can be done as:

allocate(o1);
...
if(...) goto cleanup;
...
cleanup:
deallocate(o1);

The first piece of code is pretty bad as it confuses the
reader by using a loop and the break is not very
self documenting.

The second piece of code is straight forward to read
despite using goto.

It gets even more clear in the nested case.

do {
allocate(o1);
...
if(...) break;
...
flag = FALSE;
do {
allocate(o2)
...
if(...) {
flag = TRUE;
break;
}
...
}
deallocate(o2)
if(flag) break;
...
} while(false);
deallocate(o1);

vs:

allocate(o1);
...
if(...) goto cleanup_1;
...
allocate(o2);
...
if(...) goto cleanup_1_and_2;
...
cleanup_1_and_2:
deallocate(o2);
cleanup_1:
deallocate(o1);

The nested do while loop is a big mess. The goto solution
is still simple.

Arne

On 1/31/2024 9:50 PM, Lawrence D'Oliveiro wrote:
> 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.

It is correct that MS never rewrote MSO from C++ to C#.
They did port VS to C# though.

But C# is all over. Finance, e-commerce, government etc..

The one C# app that I suspect that everyone here has used
is Wikipedia search. Wikipedia choose to do their search
using Lucene.NET instead of normal Lucene (Java based).

Arne

On 2/1/2024 9:49 PM, Arne Vajhøj wrote:
> On 1/31/2024 9:49 PM, Lawrence D'Oliveiro 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.
>
> It is pretty simple.
>
> do {
> allocate(o1);
> ...
> if(...) break;
> ...
> } while(false);
> deallocate(o1);
>
> can be done as:
>
> allocate(o1);
> ...
> if(...) goto cleanup;
> ...
> cleanup:
> deallocate(o1);
>
> The first piece of code is pretty bad as it confuses the
> reader by using a loop and the break is not very
> self documenting.
>
> The second piece of code is straight forward to read
> despite using goto.
>
> It gets even more clear in the nested case.
>
> do {
> allocate(o1);
> ...
> if(...) break;
> ...
> flag = FALSE;
> do {
> allocate(o2)
> ...
> if(...) {
> flag = TRUE;
> break;
> }
> ...
> }
> deallocate(o2)
> if(flag) break;
> ...
> } while(false);
> deallocate(o1);
>
> vs:
>
> allocate(o1);
> ...
> if(...) goto cleanup_1;
> ...
> allocate(o2);
> ...
> if(...) goto cleanup_1_and_2;
> ...
> cleanup_1_and_2:
> deallocate(o2);
> cleanup_1:
> deallocate(o1);
>
> The nested do while loop is a big mess. The goto solution
> is still simple.
>
> Arne
>

Well, I'd use:

Select <something>
Case = "1"
Some code
Case = "2"
Some other code
End Select

No need for the dreaded GoTo statement ...

But even that can be abused.

Got a friend that got carried away with Select and indenting.

When the Select statements got nested a dozen times, and indents became 8-10
tabs, and the code for each CASE was several pages long ...

If the damn code was going to be so massive and complex, he should have just
branched/performed/whatever to a separate place to do all that work.

--
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 2/1/2024 10:38 PM, Dave Froble wrote:
> On 2/1/2024 9:49 PM, Arne Vajhøj wrote:
>> It gets even more clear in the nested case.
>>
>>     do {
>>         allocate(o1);
>>         ...
>>         if(...) break;
>>         ...
>>         flag = FALSE;
>>         do {
>>             allocate(o2)
>>             ...
>>             if(...) {
>>                 flag = TRUE;
>>                 break;
>>             }
>>             ...
>>         }
>>         deallocate(o2)
>>         if(flag) break;
>>         ...
>>     } while(false);
>>     deallocate(o1);
>>
>> vs:
>>
>>     allocate(o1);
>>     ...
>>     if(...) goto cleanup_1;
>>     ...
>>     allocate(o2);
>>     ...
>>     if(...) goto cleanup_1_and_2;
>>     ...
>> cleanup_1_and_2:
>>     deallocate(o2);
>> cleanup_1:
>>     deallocate(o1);
>>
>> The nested do while loop is a big mess. The goto solution
>> is still simple.
>
> Well, I'd use:
>
> Select <something>
>     Case = "1"
>         Some code
>     Case = "2"
>         Some other code
> End Select

That code does something completely different.

> But even that can be abused.
>
> Got a friend that got carried away with Select and indenting.
>
> When the Select statements got nested a dozen times, and indents became
> 8-10 tabs, and the code for each CASE was several pages long ...
>
> If the damn code was going to be so massive and complex, he should have
> just branched/performed/whatever to a separate place to do all that work.

To quote from Linux kernel coding style doc:

<quote>
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you’re screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you’re nesting your functions too deep. Heed
that warning.
</quote>

Arne

On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:

> On 1/31/2024 9:50 PM, Lawrence D'Oliveiro wrote:
>
>> 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.
>
> It is correct that MS never rewrote MSO from C++ to C#.
> They did port VS to C# though.

Maybe, but VS Code takes an entirely different tack, using Electron (the
Chromium engine + TypeScript/JavaScript) instead. Wonder why?

> But C# is all over. Finance, e-commerce, government etc..

All that stuff that’s now in the cloud?

On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:

> The nested do while loop is a big mess.

Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you get
there. Adding a bit of a combinatorial explosion in possible cases that
have to be verified somehow.

In short, you are making a bigger mess.

On Thu, 1 Feb 2024 22:44:56 -0500, Arne Vajhøj wrote:

> To quote from Linux kernel coding style doc:
>
> <quote>
> Now, some people will claim that having 8-character indentations makes
> the code move too far to the right, and makes it hard to read on a
> 80-character terminal screen. The answer to that is that if you need
> more than 3 levels of indentation, you’re screwed anyway, and should fix
> your program.

I think this is a load of nonsense.

On Thu, 2024-02-01 at 21:43 -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?
> >
>
> Pitch it because it's Linux, not because of the goto

Oo them's flammable words. :-D
--
Tactical Nuclear Kittens

On 2/1/2024 11:48 PM, Lawrence D'Oliveiro wrote:
> On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:
>
>> On 1/31/2024 9:50 PM, Lawrence D'Oliveiro wrote:
>>
>>> 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.
>>
>> It is correct that MS never rewrote MSO from C++ to C#.
>> They did port VS to C# though.
>
> Maybe, but VS Code takes an entirely different tack, using Electron (the
> Chromium engine + TypeScript/JavaScript) instead. Wonder why?

VSC was intended to compete with Atom on Windows/Linux/macOS. VSC
was released before .NET Core. So MS did not have much of a choice.

>> But C# is all over. Finance, e-commerce, government etc..
>
> All that stuff that’s now in the cloud?

A lot of it.

But C# does not care if if the hardware it runs on is
bought or rented.

Arne

On 2/2/2024 7:38 AM, Arne Vajhøj wrote:
> On 2/1/2024 11:48 PM, Lawrence D'Oliveiro wrote:
>> On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:
>>> It is correct that MS never rewrote MSO from C++ to C#.
>>> They did port VS to C# though.
>>
>> Maybe, but VS Code takes an entirely different tack, using Electron (the
>> Chromium engine + TypeScript/JavaScript) instead. Wonder why?
>
> VSC was intended to compete with Atom on Windows/Linux/macOS. VSC
> was released before .NET Core. So MS did not have much of a choice.

Correction: they had lots of choices, but C# was just not one of them.

Arne

On 2/1/2024 11:51 PM, Lawrence D'Oliveiro wrote:
> On Thu, 1 Feb 2024 22:44:56 -0500, Arne Vajhøj wrote:
>> To quote from Linux kernel coding style doc:
>>
>> <quote>
>> Now, some people will claim that having 8-character indentations makes
>> the code move too far to the right, and makes it hard to read on a
>> 80-character terminal screen. The answer to that is that if you need
>> more than 3 levels of indentation, you’re screwed anyway, and should fix
>> your program.
>
> I think this is a load of nonsense.

Apparently Linus doesn't think so.

And while few may have worded is this blunt, then it is
generally accepted that deep nesting is a code smell and
should be refactored and code moved out to functions/methods.

The specifics may depend a little on the language. 3 may
make sense in C, but VB.NET may justify a higher value
(namespace and class add levels before even getting started
and try catch blocks plus using statements also tend to
add more levels without the levels impacting flow).

Arne

On 2/1/2024 11:50 PM, Lawrence D'Oliveiro wrote:
> On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
>> The nested do while loop is a big mess.
>
> Looks like you are adding a whole lot more lines of code in the form of
> jumps and places to jump to, and flags to control what to do when you get
> there. Adding a bit of a combinatorial explosion in possible cases that
> have to be verified somehow.

I "added" lines so that the total number of lines "increased" from
7 to 6 in the one-level example and from 20 to 12 in the two-level
example.

Arne

In article <uphsad$2fg0v$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
>
>> The nested do while loop is a big mess.
>
>Looks like you are adding a whole lot more lines of code in the form of
>jumps and places to jump to, and flags to control what to do when you get
>there. Adding a bit of a combinatorial explosion in possible cases that
>have to be verified somehow.
>
>In short, you are making a bigger mess.

Again, for this example, the code needs neither goto nor
the abstruse loop structure you wrote. See my earlier
post for details.

- Dan C.

On 2/2/2024 8:49 AM, Dan Cross wrote:
> In article <uphsad$2fg0v$3@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
>>> The nested do while loop is a big mess.
>>
>> Looks like you are adding a whole lot more lines of code in the form of
>> jumps and places to jump to, and flags to control what to do when you get
>> there. Adding a bit of a combinatorial explosion in possible cases that
>> have to be verified somehow.
>>
>> In short, you are making a bigger mess.
>
> Again, for this example, the code needs neither goto nor
> the abstruse loop structure you wrote. See my earlier
> post for details.

He cut so much that the context was not obvious.

But his post was a reply to my post with generic
.... blocks.

It is true the first specific example he provided
did not need to solve this problem if it was
restructured a little.

Arne

In article <upis9l$2kald$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/2/2024 8:49 AM, Dan Cross wrote:
>> In article <uphsad$2fg0v$3@dont-email.me>,
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
>>>> The nested do while loop is a big mess.
>>>
>>> Looks like you are adding a whole lot more lines of code in the form of
>>> jumps and places to jump to, and flags to control what to do when you get
>>> there. Adding a bit of a combinatorial explosion in possible cases that
>>> have to be verified somehow.
>>>
>>> In short, you are making a bigger mess.
>>
>> Again, for this example, the code needs neither goto nor
>> the abstruse loop structure you wrote. See my earlier
>> post for details.
>
>He cut so much that the context was not obvious.
>
>But his post was a reply to my post with generic
>... blocks.

This seems to be his MO: when presented with an
argument that disconfirms one of his preconceptions,
ignore it and respond to something else, usually
a strawman of his own creation.

>It is true the first specific example he provided
>did not need to solve this problem if it was
>restructured a little.

Yes. I suspect most of his code similarly.

- Dan C.

On 2024-01-31 21:22:33 +0000, Lawrence D'Oliveiro said:

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

Pragmatically, the difference between (pseudo-code) free(xyz) where xyz
is nulllptr or ((void*)0) or whatever, and the same brute-force if
(xyz) free(xyz); code, or a macro of same, is negligible.

No, that free ignores a null doesn't simplify the bookkeeping. There
are other languages that are easier here.

Though semi-similarly, sending a null at a method in Objective C can be
useful. And can be a source of confusion and bugs.

On OpenVMS, using VM zones reduces the memory management bookkeeping in
some contexts, as the whole zone can be freed in one shot. This
technique can be handy for command parsers, where you know you're done
with ~everything parsing-related when you're parsing the next command.

There are other trade-offs that can make this effort easier, not the
least of which is garbage collection.

Apropos of nothing, asctime() and ctime() are now (C23) deprecated.

And some semi-related reading: https://jorengarenar.github.io/blog/less-known-c

--
Pure Personal Opinion | HoffmanLabs LLC

In article <uphk35$2akla$1@dont-email.me>,
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>On 2/1/2024 8:44 PM, Scott Dorsey wrote:
>> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>> On 1/31/2024 11:17 AM, Scott Dorsey wrote:
>>>> Michael S <already5chosen@yahoo.com> wrote:
>>>>> The third option, the one I like least (an understatement) is use of
>>>>> exceptions. Despite my personal preferences, it's quite popular.
>>>>
>>>> Exceptions can be very elegant or very inelegant... and it is entirely
>>>> possible to have an exception that doesn't clean anything up at all and
>>>> just exits and lets the operating system deal with the memory. On many
>>>> systems this is a great idea because being able to exit quickly on a failure
>>>> is more important than people give it credit for. On some other systems
>>>> that have memory management issues it can lead to leakage.
>>>
>>> It is probably a bit easier to implement exceptions in languages
>>> with garbage collection and a lot easier for developers to avoid
>>> memory leak bugs.
>>
>> True, but "dispose of all memory belonging to this process" should not be
>> a big deal on a demand-paged machine. There are some architectures where
>> it can be, though.
>
>The issue is not if the process goes away but if the process
>continue after execution flow has dropped back a number of levels
>on the call stack.

Yes, but that's a different problem. I'm talking about an "abort and get
the hell out of there" routine.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Fri, 2 Feb 2024 16:43:15 -0500, Stephen Hoffman wrote:

> No, that free ignores a null doesn't simplify the bookkeeping.

It does though, in the code example I have posted elsewhere. You can just
put a sequence of unconditional free(3) calls, which is much shorter than
useless things like

if (ptr)
free(ptr);

which I see all too often.

By the way, the C++ “delete” statement is similarly specified to treat an
attempt to dispose of a NULL pointer as a harmless no-op.

On Di 30 Jan 2024 at 11:45, bill <bill.gunshannon@gmail.com> 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. Did you know that LISP has a goto?
>> It does.
>>
>>> PS: Good compilers may have detected the unreachable code. But it
>>> is still good vs bad compiler not good vs bad language.
>> The exciting part is when they tell you not to remove the unreachable
>> code,
>> because the program crashes at runtime when you do that.
>
> Many moons ago I had to try to fix a number of programs that
> crashed whenever run. Back in those days a common method was
> to add statements to display variables during execution. I
> had many cases where adding those statements made the program
> work.
>
> bill

So it was a Heisenbug :-)

'Andreas