Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402821 > unrolled thread

Real world switch () with the MPS memory pool system!

Back to article view | Back to comp.lang.c

Contents

  Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-08 08:58 +0800
    Re: Real world switch () with the MPS memory pool system! Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-08 01:31 +0000
      Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 04:26 +0800
        Re: Real world switch () with the MPS memory pool system! Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-09 20:45 +0000
          Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 05:02 +0800
            Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:28 +0800
        Re: Real world switch () with the MPS memory pool system! tfb <tfb@work.it.out> - 2026-10-10 09:45 +0000
          Re: Real world switch () with the MPS memory pool system! George Neuner <gneuner2@comcast.net> - 2026-10-11 01:13 -0400
            Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 14:45 +0800
            Re: Real world switch () with the MPS memory pool system! tfb <tfb@work.it.out> - 2026-10-11 07:28 +0000
              Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 15:41 +0800
              Re: Real world switch () with the MPS memory pool system! George Neuner <gneuner2@comcast.net> - 2026-10-11 05:29 -0400
    Re: Real world switch () with the MPS memory pool system! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 06:03 -0700
    Re: Real world switch () with the MPS memory pool system! ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-09 14:30 +0000
      Re: Real world switch () with the MPS memory pool system! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 04:41 +0800

#402821 — Real world switch () with the MPS memory pool system!

Dear comp.lang.c, comp.lang.misc, comp.lang.lisp,

Because this is a general programming example, using the MPS memory
pool system, and therefore used to /implement/ many programming lan-
guages, including Lisp, I've decided to cross post a little bit.

And because the switch () statement was a topic of discussion in comp.
lang.c only a short while ago, I present my real world example.

static mps_res_t Type_isfwd_fn( mps_addr_t addr )
{
   Type_type type = addr ;
   switch ( type->kind ) {
   case Type_forwardType: return type->fwd ;
   default: return NULL ;
   }
}

Here, /Type/ is a generic type of something, with a specific variable
named /type/.  It's not what I use in production, but will demonstrate
well enough without bothering /foo/ and /bar/.

The code is meant to check if this particular object has been forwarded
to a different generation of the garbage collector.  And I believe it
does so adequately, though I have not explicitly tested it.  All I can
say is that my previous runs of similar code have worked, and my appli-
cation didn't crash.

So the question here is, do you think this is reasonable C code, and
would you write something similar yourself?  After all, /kind/ is an
enum, and the compiler might complain if you don't handle all the cases,
and not do that if you merely use an if ().  I wouldn't know, as I don't
keep track of changes within G.C.C. nor clang anymore.

Another question is, would you consider using the MPS memory pool system
if you were to implement something garbage collected, like Common Lisp
or ML [1]?

And for the people disturbed by garbage collectors, does the above code
make you feel weird?  Do you need psychological therapy after reading my
code?



Best wishes, and happy garbage collection!

[1] Unrelated to /machine learning/, of course.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [next] | [standalone]

#402823

On 2026-10-08, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> static mps_res_t Type_isfwd_fn( mps_addr_t addr )
> {
>    Type_type type = addr ;
>    switch ( type->kind ) {
>    case Type_forwardType: return type->fwd ;
>    default: return NULL ;
>    }
> }

[...]

> So the question here is, do you think this is reasonable C code, and

Yes.

> would you write something similar yourself?  After all, /kind/ is an

As the initial draft, written by hand and not a whatever-to-C transpiler,
not the result of multiple rounds of maintenance, and not reasonably
expecting additional cases?

No.

I would write something more idiomatic:

  return type->kind == Type_forwardType ? type->fwd : NULL;

> enum, and the compiler might complain if you don't handle all the cases,

Such diagnostics tend to be suppressed in the presence of a default; it
is not possible for a switch not to handle all the cases when a default
case is present; it is most not reasonable to diagnose that which is not
possible, unless there is some good heuristic for suspecting that the
default should not actually be there.

> and not do that if you merely use an if ().  I wouldn't know, as I don't
> keep track of changes within G.C.C. nor clang anymore.
>
> Another question is, would you consider using the MPS memory pool system
> if you were to implement something garbage collected, like Common Lisp
> or ML [1]?

The intersection of "people who still write in C" and "people who want
to use someone else's C memory pool thing" is slowly converging to null.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#402859

On 10/8/2026 9:31 AM, Kaz Kylheku wrote:

On your previous points, /point taken/, and I have not much to say about
any of it.

 >> Another question is, would you consider using the MPS memory pool system
 >> if you were to implement something garbage collected, like Common Lisp
 >> or ML [1]?
 > The intersection of "people who still write in C" and "people who want
 > to use someone else's C memory pool thing" is slowly converging to null.


I see.  Well, I'm /still alive/, so while it's converging, it's not
/null/ yet.  I have to say I'm getting some enjoyment out of using the
MPS, and learning new things is always fun.

I have seen previous posters in comp.lang.c get almost if not literally
frothing at the mouth at the mere mention of garbage collectors [1].  I
do not know if any of them will deign to comment on this thread, so we
can just wait and see.

I forgot for which programming language MPS was originally designed for,
though I suspect it was ML, and the Ravenbrook website was gone last
time I checked.  The /readme/ on GitHub merely states it's been used in
successful commercial projects since 1997, so I believe it's of some
code quality.

And don't forget that just recently, people found a security bug in
OpenSSL [again] just because they neglected to include a garbage coll-
ector in the system.  Maybe they would have been better off, if they'd
just used MPS from the start?

I have included sci.crypt, and netscap.public.mozilla.crypto in this
discussion, in case any of the posters there want to comment on garbage
collection in SSL libraries.


Best wishes, and happy garbage collection!


[1] Since we rarely get to see pictures of people as they post on Use-
net it's hard to say if they are /literally/ frothing at the mouth from
anger.

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402862

On 2026-10-09, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> On 10/8/2026 9:31 AM, Kaz Kylheku wrote:
> And don't forget that just recently, people found a security bug in
> OpenSSL [again] just because they neglected to include a garbage coll-
> ector in the system.  Maybe they would have been better off, if they'd
> just used MPS from the start?

Many programs that use OpenSSL nowadays are threaded.

Threads + GC + stuff written in C => shit show

You may fix some use-after-free bug, but you introduce 17 others,
the 16th and 17th of which won't be found until 2037 and 2050.

I've pulled out my hair debugging GC problems in a single-threaded Lisp
implementation.

You have to develop all the tooling and approaches for it because
none of the regular memory debugging tools understand your GC objects.

I wanted Valgrind, so I had to integrate it, and it's not perfect.

A newly created GC object is wrongly garbage collected, perhaps just 
before it was properly made reachable. The object is reassigned to
a different purpose, but the original context uses it also. Happy
case: the object has a different type, incompatible with what the
original owner is doing, and so that blows up, and (happy again)
it happens close to where it was created. From there, there are
various shades of unhappy.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#402863

On 10/10/2026 4:45 AM, Kaz Kylheku wrote:
> On 2026-10-09, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>> On 10/8/2026 9:31 AM, Kaz Kylheku wrote:
>> And don't forget that just recently, people found a security bug in
>> OpenSSL [again] just because they neglected to include a garbage coll-
>> ector in the system.  Maybe they would have been better off, if they'd
>> just used MPS from the start?
> 
> Many programs that use OpenSSL nowadays are threaded.
> 
> Threads + GC + stuff written in C => shit show
> 
> You may fix some use-after-free bug, but you introduce 17 others,
> the 16th and 17th of which won't be found until 2037 and 2050.
> 
> I've pulled out my hair debugging GC problems in a single-threaded Lisp
> implementation.
> 
> You have to develop all the tooling and approaches for it because
> none of the regular memory debugging tools understand your GC objects.
> 
> I wanted Valgrind, so I had to integrate it, and it's not perfect.
> 
> A newly created GC object is wrongly garbage collected, perhaps just
> before it was properly made reachable. The object is reassigned to
> a different purpose, but the original context uses it also. Happy
> case: the object has a different type, incompatible with what the
> original owner is doing, and so that blows up, and (happy again)
> it happens close to where it was created. From there, there are
> various shades of unhappy.
> 

That's fair.  And I deplore your lack of hair.  Mine -- as seen on Blue-
Sky -- is not from fighting garbage collectors.  Though I suppose I
could put more pictures of myself there.  So I'll keep that in mind as
something to do over the weekend.

Now, on debugging garbage collectors, the MPS manual has this chapter on
the subject,

   https://memory-pool-system.readthedocs.io/en/latest/guide/debug.html

and I have to say that I have not had the displeasure of needing to use
it -- yet.

And on the subject of garbage collection and threads, the Memory Pool
manual has this to say on the subject.

   The MPS is designed to work with multi-threaded programs. Functions in
   the C interface are thread safe, except in a few documented cases. See
   Threads. The allocation point protocol provides fast lock-free
   allocation on multiple threads simultaneously. See Allocation.

So it would seem, at first glance, that the OpenSSL security issue --
I'll link it if anyone cares to ask, but it should be readily found --
would not have happened if they'd used the MPS from the start.  And
since they don't, and never did, there is no second glance to prove me
wrong.

I'll just note that I made the personal promise to myself, that I'd
never contribute code to OpenSSL, so I will not undertake the effort
of proving myself wrong in this case.


Best wishes, and happy garbage collection!

[1] I have not dug into the intern guts of it, and my memory of that
part of the manual is vague.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402931

On 10/10/2026 5:02 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 10/10/2026 4:45 AM, Kaz Kylheku wrote:
>> On 2026-10-09, Johann 'Myrkraverk' Oskarsson 
>> <johann@myrkraverk.invalid> wrote:
>>> On 10/8/2026 9:31 AM, Kaz Kylheku wrote:
>>> And don't forget that just recently, people found a security bug in
>>> OpenSSL [again] just because they neglected to include a garbage coll-
>>> ector in the system.  Maybe they would have been better off, if they'd
>>> just used MPS from the start?
>>
>> Many programs that use OpenSSL nowadays are threaded.
>>
>> Threads + GC + stuff written in C => shit show
>>
>> You may fix some use-after-free bug, but you introduce 17 others,
>> the 16th and 17th of which won't be found until 2037 and 2050.
>>
>> I've pulled out my hair debugging GC problems in a single-threaded Lisp
>> implementation.
>>
>> You have to develop all the tooling and approaches for it because
>> none of the regular memory debugging tools understand your GC objects.
>>
>> I wanted Valgrind, so I had to integrate it, and it's not perfect.
>>
>> A newly created GC object is wrongly garbage collected, perhaps just
>> before it was properly made reachable. The object is reassigned to
>> a different purpose, but the original context uses it also. Happy
>> case: the object has a different type, incompatible with what the
>> original owner is doing, and so that blows up, and (happy again)
>> it happens close to where it was created. From there, there are
>> various shades of unhappy.
>>
> 
> That's fair.  And I deplore your lack of hair.  Mine -- as seen on Blue-
> Sky -- is not from fighting garbage collectors.  Though I suppose I
> could put more pictures of myself there.  So I'll keep that in mind as
> something to do over the weekend.
> 
> Now, on debugging garbage collectors, the MPS manual has this chapter on
> the subject,
> 
>    https://memory-pool-system.readthedocs.io/en/latest/guide/debug.html
> 
> and I have to say that I have not had the displeasure of needing to use
> it -- yet.
> 
> And on the subject of garbage collection and threads, the Memory Pool
> manual has this to say on the subject.
> 
>    The MPS is designed to work with multi-threaded programs. Functions in
>    the C interface are thread safe, except in a few documented cases. See
>    Threads. The allocation point protocol provides fast lock-free
>    allocation on multiple threads simultaneously. See Allocation.
> 
> So it would seem, at first glance, that the OpenSSL security issue --
> I'll link it if anyone cares to ask, but it should be readily found --
> would not have happened if they'd used the MPS from the start.  And
> since they don't, and never did, there is no second glance to prove me
> wrong.
> 
> I'll just note that I made the personal promise to myself, that I'd
> never contribute code to OpenSSL, so I will not undertake the effort
> of proving myself wrong in this case.
> 
> 
> Best wishes, and happy garbage collection!
> 
> [1] I have not dug into the intern guts of it, and my memory of that
> part of the manual is vague.

The OpenSSL vulnerability I was thinking of is HollowByte, and from July
2026 should be fresh in everyone's memory.  For the few lurkers of comp.
lang.c who don't keep updated with OpenSSL and named vulnerabilities, I
link you the following article,

   https://my-ssl.com/learn/openssl-hollowbyte-vulnerability-2026

and quote the TL;DR.

     HollowByte is the latest OpenSSL vulnerability, disclosed 17 July
     2026. An unauthenticated attacker sends an 11-byte malformed TLS
     ClientHello, and a handshake worker on your server hangs onto the
     socket and its buffer instead of releasing them. Repeat the request
     a few thousand times a second and the server stops accepting new
     HTTPS connections. It affects supported OpenSSL 3.x branches shipped
     before the July 2026 fix. Upgrade the openssl package from your
     distro and restart every daemon that links it — a package update
     alone won't help until you restart the processes. No memory
     disclosure, no key leak, so you do not need to reissue your
     certificate. Behind Cloudflare, an AWS ALB, or an already-patched
     reverse proxy? You're shielded at the edge, but patch the origin
     anyway before the next audit.

     We've walked through this response cycle on production fleets for
     every OpenSSL CVE since Heartbleed. What follows is the checklist we
     actually run — versions, commands, mitigations, and the reissue
     question we get asked every single time.

And while I can't be sure, I'm fairly certain some sort of garbage coll-
ector in the new connection parser [1] would have prevented this.  But
keep in mind OpenSSL has been plagued with memory leaks since its incep-
tion, so it's not like memory usage was high on anyone's priority list.

I mean, didn't Heartbleed happen because people were lazy about memory
boundaries?  Why bother free() with any of the memory, right?  It can
be read later on with the right payload incantation anyway.

So yeah; anyone making a new S.S.L. library from scratch is going to
have to deal with this attack too; and hopefully they'll use some sort
of garbage collection in the new connection parser.



Best wishes, and happy bugs in OpenSSL!


[1] Surely, with a brand new connection, you can reuse the previous att-
emtp when you get more data, right?
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402872

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

> I forgot for which programming language MPS was originally designed for,
> though I suspect it was ML, and the Ravenbrook website was gone last
> time I checked. 

Dylan, I am almost certain.

-- 
tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#402939

On Sat, 10 Oct 2026 09:45:19 -0000 (UTC), tfb <tfb@work.it.out> wrote:

>Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>
>> I forgot for which programming language MPS was originally designed for,
>> though I suspect it was ML, and the Ravenbrook website was gone last
>> time I checked. 
>
>Dylan, I am almost certain.

I /don't/ know for certain, but according to its own history MPS was
developed by Harlequin - which made a Lisp.  Dylan came from Apple.


https://memory-pool-system.readthedocs.io/en/latest/bib.html#brooksby02

[toc] | [prev] | [next] | [standalone]

#402941

On 10/11/2026 1:13 PM, George Neuner wrote:
> On Sat, 10 Oct 2026 09:45:19 -0000 (UTC), tfb <tfb@work.it.out> wrote:
> 
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>>
>>> I forgot for which programming language MPS was originally designed for,
>>> though I suspect it was ML, and the Ravenbrook website was gone last
>>> time I checked.
>>
>> Dylan, I am almost certain.
> 
> I /don't/ know for certain, but according to its own history MPS was
> developed by Harlequin - which made a Lisp.  Dylan came from Apple.
> 
> 
> https://memory-pool-system.readthedocs.io/en/latest/bib.html#brooksby02

In my defense, I thought it was ML, because their source repository has
MLWorks,

   https://github.com/Ravenbrook/mlworks

but Dylan and Lisp are also strong contenders.  However, upon second
glance at the sources, it looks like it has its own non-MPS garbage
collector at

   https://github.com/Ravenbrook/mlworks/blob/master/src/rts/src/gc.c

so /probably not that/.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402945

George Neuner <gneuner2@comcast.net> wrote:

> 
> I /don't/ know for certain, but according to its own history MPS was
> developed by Harlequin - which made a Lisp.  Dylan came from Apple.
> 

Harlequin had a Dylan implementation, DylanWorks (I don't remember if it
shipped).  MLWorks was earlier and some of the people who did MPS had
worked on its memory management.  MPS seems to have been developed for
DylanWorks however. 
https://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ makes
the history reasonably clear.


-- 
tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#402949

On 10/11/2026 3:28 PM, tfb wrote:
> George Neuner <gneuner2@comcast.net> wrote:
> 
>>
>> I /don't/ know for certain, but according to its own history MPS was
>> developed by Harlequin - which made a Lisp.  Dylan came from Apple.
>>
> 
> Harlequin had a Dylan implementation, DylanWorks (I don't remember if it
> shipped).  MLWorks was earlier and some of the people who did MPS had
> worked on its memory management.  MPS seems to have been developed for
> DylanWorks however.
> https://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ makes
> the history reasonably clear.
> 
> 

Thank you.  For -- I'm not sure how long -- the Ravenbrook website was
erroring out on me.  And now it works.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402959

On Sun, 11 Oct 2026 07:28:07 -0000 (UTC), tfb <tfb@work.it.out> wrote:

>George Neuner <gneuner2@comcast.net> wrote:
>
>> 
>> I /don't/ know for certain, but according to its own history MPS was
>> developed by Harlequin - which made a Lisp.  Dylan came from Apple.
>> 
>
>Harlequin had a Dylan implementation, DylanWorks (I don't remember if it
>shipped).  MLWorks was earlier and some of the people who did MPS had
>worked on its memory management.  MPS seems to have been developed for
>DylanWorks however. 
>https://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ makes
>the history reasonably clear.

Ah.  I was not aware that Harlequin had a Dylan implementation. 
Thank you for that!


I have a vague recollection (circa late 90s/early 00s when I was doing
compiler work) that MPS was a library for region memory management
[regions per Tofte, et.al.]  

I didn't see a lot of potential then ... but it has been a long time.
 8-)

[toc] | [prev] | [next] | [standalone]

#402830

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> Dear comp.lang.c, comp.lang.misc, comp.lang.lisp,
>
> Because this is a general programming example, using the MPS memory
> pool system, and therefore used to /implement/ many programming lan-
> guages, including Lisp, I've decided to cross post a little bit.

The intersection of what you're interested in and the interests
of people who read comp.lang.c is roughly the size of a hydrogen
atom.

[toc] | [prev] | [next] | [standalone]

#402853

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>So the question here is, do you think this is reasonable C code, and
>would you write something similar yourself?  After all, /kind/ is an
>enum, and the compiler might complain if you don't handle all the cases,

  I see no problem with the code after a first quick reading.

  As a matter of style, I might have added a "const" here or there.
  However, this is less important for simple small functions.

  The fact that this function is small makes it actually quite
  readable.

  A type such as "mps_addr_t" might hide an asterisk. So, "mps *"
  might be more readable than "mps_addr_t" because it uses the
  language to express the addressness instead of less clear names
  and allows the adding of "const"s, as in "mps const * const" 
  where appropriate. OTOH, sometimes one wants to hide such details,
  but then one also would avoid inserting "addr_t" into a name.

  The functions lacks documentation such as can be written using
  Doxygen or something. So it's intended semantics are unknown and
  we cannot review that aspect.

Newsgroups: comp.lang.c,comp.lang.misc,comp.lang.lisp
Followup-To: comp.lang.c

[toc] | [prev] | [next] | [standalone]

#402861

On 10/9/2026 10:30 PM, Stefan Ram wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>> So the question here is, do you think this is reasonable C code, and
>> would you write something similar yourself?  After all, /kind/ is an
>> enum, and the compiler might complain if you don't handle all the cases,
> 
>    I see no problem with the code after a first quick reading.
> 
>    As a matter of style, I might have added a "const" here or there.
>    However, this is less important for simple small functions.
> 
>    The fact that this function is small makes it actually quite
>    readable.
> 
>    A type such as "mps_addr_t" might hide an asterisk. So, "mps *"
>    might be more readable than "mps_addr_t" because it uses the
>    language to express the addressness instead of less clear names
>    and allows the adding of "const"s, as in "mps const * const"
>    where appropriate. OTOH, sometimes one wants to hide such details,
>    but then one also would avoid inserting "addr_t" into a name.
> 
>    The functions lacks documentation such as can be written using
>    Doxygen or something. So it's intended semantics are unknown and
>    we cannot review that aspect.
> 
> Newsgroups: comp.lang.c,comp.lang.misc,comp.lang.lisp
> Followup-To: comp.lang.c

The type mps_addr_t is from the MPS library, obviously, and I just use
the library as the makers -- though now gone -- envisioned.

No, there's no documentation.  It's explicitly written for a function
pointer in the MPS library, which does document its purpose.  I don't
know about you, but I don't feel the need to document all such functions
once I'm starting to know how the library works.

Though, it's not a bad practice.  Documenting for instance the callback
functions in Expat XML, which I'm sure everyone here in comp.lang.c has
experimented with, if not used in production from time to time, is quite
a good practice; especially when they keep track of where in the XML
hierarchy they are with a stack library.

I can recommend Loudon's /Mastering Algorithms in C/ stack library for
student projects, prototypes, and experiments; but not necessarily pro-
duction code.

In similar fashion, the renowned Mustache library by Jose Bollo,

   https://gitlab.com/jobol/mustach

needs callbacks; I admit I've not used the newer version 2 yet.  And
they can be documented similarly with Doxygen.

Though I have to say, I quite dislike Doxygen as a product.  Too many
open source projects have come to write /documented with Doxygen/, but
then nothing gets written.  So we get all kinds of fancy H.T.M.L. with
clickable links and maybe even fancy class diagrams, but nobody bothered
to write the documentation a hapless user of the library would like to
use.

So there is the argument that Doxygen has contributed to a /lack/ of
documentation in the open source world, quite directly, by hiding the
fact nothing was ever written of the supposed documentation.

Of course, we cannot directly associate that social phenomenon to the
makers of Doxygen, can we?  After all, coders aren't writers, and rather
dump code on GitHub, GitLab, or previously, directly on Usenet, F.T.P.
and similarly obscure places, without ever writing anything about what
it's for, and then be perplexed nobody comments nor seems to use it.


Best wishes, and happy documenting your own code!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web