On Fri, 22 Nov 2024 10:45:58 +0000, Richard Kettlewell wrote:

> More recent languages have other options (‘defer’, ‘finally’,
> destructors, etc).

And then there are “continuations”. You find these in Scheme, not so much
in other languages. They are a generalized control construct. They can be
used to implement looping-with-multiple-exits, exceptions and coroutines,
but not (easily) for arbitrary gotos.

In other words, you can consider them to be a generalized *structured*
control construct.

On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:

> All my programs contain a routine called quit_cleanup(); it takes a
> single argument, which is either an error message or NULL.
> It frees all allocated memory, closes any open files, etc.

But all that is unnecessary if your program is terminating anyway.

In *nix C code, a common convention is

if («call failed»)
{
perror(«doing what»);
exit(«nonzero error code»);
} /*if*/

<https://manpages.debian.org/3/perror.3.en.html>

On Fri, 22 Nov 2024 13:37:43 +0000, Pancho wrote:

> In OO, switch/case statements were deprecated too :-) I can't remember
> exactly why. I think it was because we were supposed to use polymorphism
> instead.

Switch/case expressions? With cases based on different types, perhaps?

info_type = infoptr.contents.info_type
infoptr = ct.cast \
(
infoptr,
ct.POINTER
(
{
FANOTIFY.EVENT_INFO_TYPE_FID : FANOTIFY.event_info_fid,
FANOTIFY.EVENT_INFO_TYPE_DFID_NAME : FANOTIFY.event_info_fid,
FANOTIFY.EVENT_INFO_TYPE_DFID : FANOTIFY.event_info_fid,
FANOTIFY.EVENT_INFO_TYPE_PIDFD : FANOTIFY.event_info_pidfd,
FANOTIFY.EVENT_INFO_TYPE_ERROR : FANOTIFY.event_info_error,
}[info_type]
)
)
additional.append(infoptr)
if info_type == FANOTIFY.EVENT_INFO_TYPE_DFID_NAME :
nameptr = ct.cast \
(
ct.cast(infoptr, ct.c_void_p).value
+
ct.sizeof(FANOTIFY.event_info_fid)
+
infoptr.contents.handle.handle_bytes,
ct.c_char_p
)
additional.append(nameptr.value)
#end if
next += infolen
remaining -= infolen

On Fri, 22 Nov 2024 19:30:24 +0000, The Natural Philosopher wrote:

> The 'nogoto' was really a fool's rule.

I have never written a goto in (production) C code.

On Fri, 22 Nov 2024 18:53:29 GMT, Charlie Gibbs wrote:

> After all, what is a subroutine call other than a
> GOTO paired with a "come from"?

A stack of call frames and return addresses.

LIFO discipline applies.

On 11/22/24 19:30, The Natural Philosopher wrote:

>> Coding is always a balance between flexibility and clarity, there is
>> no "right" answer. You can make code more flexible by adding another
>> layer of indirection, but it becomes harder to understand.
>>
>>
> I echo that. The 'nogoto' was really a fool's rule. The wise man's
> guidance was 'make it clear what you are doing because you  or someone
> else - may need to understand it in a years time'
> I dpnt find OO in general makes code easier to understand.
>

It's hard for me to understand reluctance to use OO. I learnt Smalltalk
before I learnt C. I never did much development in C, mainly
maintenance, but when I did it had an OO feel. When C++ came along I was
very happy.

To me saying you don't like OO is a bit like saying you don't like
structs. Yes, instead of a struct you could use a block of memory and
offsets, but why would you want to when you have a struct.

I find it hard to imagine any other way of coding.

On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:

> I learnt Smalltalk before I learnt C.

Smalltalk is an interesting language. But I think it’s considered a little
too unconventional these days ...

Does it do multiple inheritance? I can’t remember.

On 11/23/24 00:44, Lawrence D'Oliveiro wrote:
> On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:
>
>> I learnt Smalltalk before I learnt C.
>
> Smalltalk is an interesting language. But I think it’s considered a little
> too unconventional these days ...
>
> Does it do multiple inheritance? I can’t remember.

No, not that I remember. Classes, Metaclasses, Single inheritance, very
clean. I think Smalltalk was more a teaching tool rather than anything
people used commercially. It was early enough in my development that OO
concepts were like a first language to me. Perhaps if I had had a solid
coding background in something like C before being introduced to OO, I
would think differently.

On Sat, 23 Nov 2024 01:08:16 +0000, Pancho wrote:

> On 11/23/24 00:44, Lawrence D'Oliveiro wrote:
>>
>> On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:
>>
>>> I learnt Smalltalk before I learnt C.
>>
>> Smalltalk is an interesting language. But I think it’s considered a
>> little too unconventional these days ...
>>
>> Does it do multiple inheritance? I can’t remember.
>
> No, not that I remember. Classes, Metaclasses, Single inheritance, very
> clean.

“Metaclasses” were just a bit of a hack to implement what Python would
call “classmethods”. Python also has “metaclasses”, in the sense that
classes, being first-class objects, must be instances of something -- and
that something is the metaclass.

Not sure if any other language has that meaning for “metaclass”.

> I think Smalltalk was more a teaching tool rather than anything
> people used commercially.

I’m pretty sure it has been used commercially, back in the 1980s or
so, maybe even the 1990s. I found a mention of a game framework
originally written in Squeak
<https://www.theregister.com/2023/03/23/croquet_for_unity/>, though
the main news in the article is that it had been reworked in ... wait
for it ... JavaScript.

On Sat, 23 Nov 2024 01:08:16 +0000, Pancho wrote:

> On 11/23/24 00:44, Lawrence D'Oliveiro wrote:
>> On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:
>>
>>> I learnt Smalltalk before I learnt C.
>>
>> Smalltalk is an interesting language. But I think it’s considered a
>> little too unconventional these days ...
>>
>> Does it do multiple inheritance? I can’t remember.
>
> No, not that I remember. Classes, Metaclasses, Single inheritance, very
> clean. I think Smalltalk was more a teaching tool rather than anything
> people used commercially. It was early enough in my development that OO
> concepts were like a first language to me. Perhaps if I had had a solid
> coding background in something like C before being introduced to OO, I
> would think differently.

A person's experience is definitely a factor. My first language was
FORTRAN IV although I never did much with it. As microcontrollers started
to appear in industrial applications I mostly worked wiht assembly or C,
viewing C very much as an abstraction of assembly.

The Boston branch of the IEEE Computer Society was quite active and I
recall discussions of 'C with Classes' in the early '80s that eventually
became C++.

I think C++ was a premature birth. Stroustrup's first and second editions
used objects sparingly compared to what many of the popular texts did when
trying to illustrate inheritance, polymorphism, and so forth. The STL and
Standard Library were years in the future so you had companies like
Microsoft coming up with MFC. Then there was Stroustrup's little quip
about C++ making it difficult to shoot yourself in the foot but when you
did you blew your whole leg off.

Esri used C++ for their Arc Objects API so I used C++ but it never became
my favorite language and the C++ part was mostly manipulating the objects
rather than overall structure. I use C# and Python so I don't dislike OO
when used sparingly. I might even like C++ these days although I have no
call to use it. When our department moved I looked through my dusty C++
reference books from 25 years ago and realized they are museum relics.

On 11/22/24 12:51 AM, Lawrence D'Oliveiro wrote:
> On Thu, 21 Nov 2024 20:19:55 -0700, Don_from_AZ wrote:
>
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 21/11/2024 07:20, 186282@ud0s4.net wrote:
>>>>
>>>> I take it you're also not a fan of Perl  🙂
>>>
>>> Perfectly Execrable Rubbish Language
>>
>> I've heard it called:
>>
>> "Pathologically Eclectic Rubbish Lister"
>
> It changed the meaning of the term “high-level language” forever.

Well ... glad to see my opinion of Perl is
not unique :-)

Way back I bought the usual "Learn Perl" book with
the camel on the front. About two chapters in I
said "WHY ???".

I've had to tweak a few Perl scripts that for
SOME reason other developers used in their apps,
but it's NOT pleasant. As I remember "ZoneMinder"
uses some Perl - and sometimes you need to tweak
some lines to get best performance ......

ZM is a pretty good app - but CAN be a horrible
CPU/mem hog if you don't set everything perfectly.
The docs are only JUST so good at explaining how
to set everything perfectly ....

On Fri, 22 Nov 2024 23:57:58 -0500, 186282@ud0s4.net wrote:

> Way back I bought the usual "Learn Perl" book with the camel on the
> front. About two chapters in I said "WHY ???".

Perl was designed by a bunch of clever people, who understood the sort of
features they wanted to add. The trouble is, they did it in kind of an ad-
hoc way, so the syntax, like Topsy, “just growed”.

On 11/22/24 1:53 PM, Charlie Gibbs wrote:
> On 2024-11-22, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 22/11/2024 10:45, Richard Kettlewell wrote:
>>
>>> The one place I’ll use a goto (in C) is to branch to unified cleanup
>>> code in an error case, usually using a macro both to emphasize what’s
>>> going on and to stop the error-handling guff from dominating what the
>>> reader sees.
>>
>> +1
>> GOTO snafu_nuclear_option... :-)
>
> All my programs contain a routine called quit_cleanup(); it takes
> a single argument, which is either an error message or NULL.
> It frees all allocated memory, closes any open files, etc.
> (all such variables are global and I initialize them to NULL
> or whatever other value is appropriate). Then, if the error
> message argument is not NULL, it displays and/or logs the
> message and calls exit() with a non-zero argument. If the
> error message argument is NULL, it simply calls exit(0).
> I can call it from anywhere, and it guarantees an orderly shutdown.

Seems wise.

On 2024-11-22, candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote at 18:53 this Friday (GMT):
>
>> On 2024-11-22, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> On 22/11/2024 10:45, Richard Kettlewell wrote:
>>>
>>>> The one place I’ll use a goto (in C) is to branch to unified cleanup
>>>> code in an error case, usually using a macro both to emphasize what’s
>>>> going on and to stop the error-handling guff from dominating what the
>>>> reader sees.
>>>
>>> +1
>>> GOTO snafu_nuclear_option... :-)
>>
>> All my programs contain a routine called quit_cleanup(); it takes
>> a single argument, which is either an error message or NULL.
>> It frees all allocated memory, closes any open files, etc.
>> (all such variables are global and I initialize them to NULL
>> or whatever other value is appropriate). Then, if the error
>> message argument is not NULL, it displays and/or logs the
>> message and calls exit() with a non-zero argument. If the
>> error message argument is NULL, it simply calls exit(0).
>> I can call it from anywhere, and it guarantees an orderly shutdown.
>
> Unless you specifically use your own allocation wrapper that adds it to
> an internal list, how do you deallocate "all" the allocations you've
> done?

I've occasionally considered making a list, but never got around to
implementing such a scheme. So it's the good old-fashioned way -
free each allocation one by one and hope you don't forget one.
Even then, leaks would be unlikely, because I try to close or free
resources as soon as I'm done with them, and the de-allocations
in quit_cleanup() are mostly belt-and-suspenders code.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 22 Nov 2024 19:30:24 +0000, The Natural Philosopher wrote:
>
>> The 'nogoto' was really a fool's rule.
>
> I have never written a goto in (production) C code.

I have two in a large old production program - well, actually
12, but there are only two target labels. Someday I might
get around to re-working the code to eliminate them, but
there's always something else to do first, and that part
of the program has been stable for 30 years.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>
>> All my programs contain a routine called quit_cleanup(); it takes a
>> single argument, which is either an error message or NULL.
>> It frees all allocated memory, closes any open files, etc.
>
> But all that is unnecessary if your program is terminating anyway.
>
> In *nix C code, a common convention is
>
> if («call failed»)
> {
> perror(«doing what»);
> exit(«nonzero error code»);
> } /*if*/
>
> <https://manpages.debian.org/3/perror.3.en.html>

Perhaps, but I'm a belt-and-suspenders guy - I like
to explicitly free everything come hell or high water.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:

> So it's the good old-fashioned way - free
> each allocation one by one and hope you don't forget one.

One thing that helps is that free(3) is idempotent: calling it on a NULL
pointer is a harmless no-op, so there is no need to check for NULL before
calling it. So my standard technique (simplifying somewhat) is

* Initialize all dynamic storage pointers in this scope to NULL
* Do the various allocations, processing, etc
* Unconditionally free() all dynamic storage pointers in this scope,
allocated or not.

This keeps the code as simple as I can make it.

On Sat, 23 Nov 2024 07:09:11 GMT, Charlie Gibbs wrote:

> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>
>>> All my programs contain a routine called quit_cleanup(); it takes a
>>> single argument, which is either an error message or NULL.
>>> It frees all allocated memory, closes any open files, etc.
>>
>> But all that is unnecessary if your program is terminating anyway.
>
> Perhaps, but I'm a belt-and-suspenders guy - I like to explicitly free
> everything come hell or high water.

That actually slows down program termination.

On 11/23/24 01:41, Lawrence D'Oliveiro wrote:
> On Sat, 23 Nov 2024 01:08:16 +0000, Pancho wrote:
>
>> On 11/23/24 00:44, Lawrence D'Oliveiro wrote:
>>>
>>> On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:
>>>
>>>> I learnt Smalltalk before I learnt C.
>>>
>>> Smalltalk is an interesting language. But I think it’s considered a
>>> little too unconventional these days ...
>>>
>>> Does it do multiple inheritance? I can’t remember.
>>
>> No, not that I remember. Classes, Metaclasses, Single inheritance, very
>> clean.
>
> “Metaclasses” were just a bit of a hack to implement what Python would
> call “classmethods”.

I think the Smalltalk idea of treating classes as objects, is the
opposite of a hack. It is a very clean and simple idea. Even today I
still think metaclasses are the easiest way to imagine some behaviour of
OO languages.

I would say C++ static methods and static variables are a hack. C# type
reflection is a hack. Just as value types are a hack in C#. Things that
are sensible for performance reasons, but that add complexity.

It was easy to see where Python metaclasses came from.

> Python also has “metaclasses”, in the sense that
> classes, being first-class objects, must be instances of something -- and
> that something is the metaclass.
>
> Not sure if any other language has that meaning for “metaclass”.
>
>> I think Smalltalk was more a teaching tool rather than anything
>> people used commercially
>
> I’m pretty sure it has been used commercially, back in the 1980s or
> so, maybe even the 1990s.

Probably, just as some people program in Haskell or Prolog.

On 11/23/24 02:29, rbowman wrote:
> On Sat, 23 Nov 2024 01:08:16 +0000, Pancho wrote:
>
>> On 11/23/24 00:44, Lawrence D'Oliveiro wrote:
>>> On Fri, 22 Nov 2024 23:07:19 +0000, Pancho wrote:
>>>
>>>> I learnt Smalltalk before I learnt C.
>>>
>>> Smalltalk is an interesting language. But I think it’s considered a
>>> little too unconventional these days ...
>>>
>>> Does it do multiple inheritance? I can’t remember.
>>
>> No, not that I remember. Classes, Metaclasses, Single inheritance, very
>> clean. I think Smalltalk was more a teaching tool rather than anything
>> people used commercially. It was early enough in my development that OO
>> concepts were like a first language to me. Perhaps if I had had a solid
>> coding background in something like C before being introduced to OO, I
>> would think differently.
>
> A person's experience is definitely a factor. My first language was
> FORTRAN IV although I never did much with it.

FORTRAN 77 was probably the first language I ever read about, but for
some reason it never went further than superficial reading.

> As microcontrollers started
> to appear in industrial applications I mostly worked wiht assembly or C,
> viewing C very much as an abstraction of assembly.
>
> The Boston branch of the IEEE Computer Society was quite active and I
> recall discussions of 'C with Classes' in the early '80s that eventually
> became C++.
>

Did it?, there was Objective C too.

> I think C++ was a premature birth. Stroustrup's first and second editions
> used objects sparingly compared to what many of the popular texts did when
> trying to illustrate inheritance, polymorphism, and so forth.

I'm not sure which version I read, the grey one. It was Ok, not K&R
quality, but still readable.

> The STL and
> Standard Library were years in the future so you had companies like
> Microsoft coming up with MFC.

We used the RougeWave library for container classes.

> Then there was Stroustrup's little quip
> about C++ making it difficult to shoot yourself in the foot but when you
> did you blew your whole leg off.
>
> Esri used C++ for their Arc Objects API so I used C++ but it never became
> my favorite language and the C++ part was mostly manipulating the objects
> rather than overall structure.

I genuinely like OO design. It is the way I naturally think of program
structure. It maps well to designing service orientated architectures.

> I use C# and Python so I don't dislike OO
> when used sparingly. I might even like C++ these days although I have no
> call to use it. When our department moved I looked through my dusty C++
> reference books from 25 years ago and realized they are museum relics.

I haven't used C++ properly for about 25 years.

On 11/23/24 07:44, Lawrence D'Oliveiro wrote:
> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>
>> So it's the good old-fashioned way - free
>> each allocation one by one and hope you don't forget one.
>
> One thing that helps is that free(3) is idempotent:

It isn't idempotent.

> calling it on a NULL
> pointer is a harmless no-op,

OK it is idempotent on NULL, but not in general.

On 11/23/24 07:09, Charlie Gibbs wrote:
> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>
>>> All my programs contain a routine called quit_cleanup(); it takes a
>>> single argument, which is either an error message or NULL.
>>> It frees all allocated memory, closes any open files, etc.
>>
>> But all that is unnecessary if your program is terminating anyway.
>>
>> In *nix C code, a common convention is
>>
>> if («call failed»)
>> {
>> perror(«doing what»);
>> exit(«nonzero error code»);
>> } /*if*/
>>
>> <https://manpages.debian.org/3/perror.3.en.html>
>
> Perhaps, but I'm a belt-and-suspenders guy - I like
> to explicitly free everything come hell or high water.
>

I can see that is nice, to understand what you have, but it sounds like
hard work.

However there are some resource you do need to explicitly
free/release/close, some database locks for instance.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>> So it's the good old-fashioned way - free
>> each allocation one by one and hope you don't forget one.
>
> One thing that helps is that free(3) is idempotent:

It is not. Freeing the same non-null pointer twice is a bug (and a
common source of vulnerabilities).

> calling it on a NULL pointer is a harmless no-op, so there is no need
> to check for NULL before calling it. So my standard technique
> (simplifying somewhat) is

‘free() and null out all copies of the pointer that can ever reach
free() in the future’ is idempotent, if you can get it right (which is
usually not too hard in a well-organized program).

--
https://www.greenend.org.uk/rjk/

On 23/11/2024 04:57, 186282@ud0s4.net wrote:
> On 11/22/24 12:51 AM, Lawrence D'Oliveiro wrote:
>> On Thu, 21 Nov 2024 20:19:55 -0700, Don_from_AZ wrote:
>>
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>
>>>> On 21/11/2024 07:20, 186282@ud0s4.net wrote:
>>>>>
>>>>> I take it you're also not a fan of Perl  🙂
>>>>
>>>> Perfectly Execrable Rubbish Language
>>>
>>> I've heard it called:
>>>
>>>    "Pathologically Eclectic Rubbish Lister"
>>
>> It changed the meaning of the term “high-level language” forever.
>
>
>   Well ... glad to see my opinion of Perl is
>   not unique  :-)
>
>   Way back I bought the usual "Learn Perl" book with
>   the camel on the front. About two chapters in I
>   said "WHY ???".
>
I just saw the type of people who created enormous scripts in it, and
thought 'total wankers' They typically read instruction manuals as a
hobby...

If a script gets that big it should be in a different language altogether.

It reminds me of a cartoon picture of a nerd saying 'I use a Unix based
operating system. My computers crash about as often as I get laid'

--
“when things get difficult you just have to lie”

― Jean Claud Jüncker

On 23/11/2024 07:09, Charlie Gibbs wrote:
> On 2024-11-22, candycanearter07
> <candycanearter07@candycanearter07.nomail.afraid> wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote at 18:53 this Friday (GMT):
>>
>>> On 2024-11-22, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>
>>>> On 22/11/2024 10:45, Richard Kettlewell wrote:
>>>>
>>>>> The one place I’ll use a goto (in C) is to branch to unified cleanup
>>>>> code in an error case, usually using a macro both to emphasize what’s
>>>>> going on and to stop the error-handling guff from dominating what the
>>>>> reader sees.
>>>>
>>>> +1
>>>> GOTO snafu_nuclear_option... :-)
>>>
>>> All my programs contain a routine called quit_cleanup(); it takes
>>> a single argument, which is either an error message or NULL.
>>> It frees all allocated memory, closes any open files, etc.
>>> (all such variables are global and I initialize them to NULL
>>> or whatever other value is appropriate). Then, if the error
>>> message argument is not NULL, it displays and/or logs the
>>> message and calls exit() with a non-zero argument. If the
>>> error message argument is NULL, it simply calls exit(0).
>>> I can call it from anywhere, and it guarantees an orderly shutdown.
>>
>> Unless you specifically use your own allocation wrapper that adds it to
>> an internal list, how do you deallocate "all" the allocations you've
>> done?
>
> I've occasionally considered making a list, but never got around to
> implementing such a scheme. So it's the good old-fashioned way -
> free each allocation one by one and hope you don't forget one.
> Even then, leaks would be unlikely, because I try to close or free
> resources as soon as I'm done with them, and the de-allocations
> in quit_cleanup() are mostly belt-and-suspenders code.
>
If you never explicitly allocated memory you can, in C, do a longjmp()
back to a stack that implicity frees any local variables.

I dislike the use of malloc and friends in daemons that run forever.
Exiting a program cleans up anyway, Its programs where you are
repeatedly allocating and deallocating memory that give problems. Usual
due to 'unusual' exits that fail to clean up in the normal way.

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy