mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <>
To: "Thomas Stüfe" <>
Subject: Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
Date: Wed, 29 Jun 2022 18:15:21 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> ("Thomas =?utf-8?Q?St=C3=BCfe=22's?= message of "Wed, 29 Jun 2022 17:49:55 +0200")

* Thomas Stüfe:

> Greetings,
> I have a small question about the way muslc implements the CPU_ALLOC and CPU_FREE
> macros. 
> I see them defined in sched.h as:
> #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
> #define CPU_FREE(set) free(set)
> whereas the glibc defines them as calls to functions __sched_cpu_alloc() and
> __sched_cpufree():
> #define __CPU_ALLOC(count) __sched_cpualloc (count)
> #define __CPU_FREE(cpuset) __sched_cpufree (cpuset)
> in the end both variants allocate from C-heap, but the muslc variant
> gets inlined directly into the calling code. If that calling code has
> a function "free" or "calloc" (okay, less likely) these get called
> instead. Could also be a class local method in C++.

calloc and free can be macros, and if an implementation exercises this
possibility, you will have some trouble defining your own functions of
the same name.  We ran into this issue when we added an iszero macro to
glibc as part of support for future C revisions.  In the end, we had to
use an alternative C++ construct in C++ mode instead of the preprocessor
macro we use for C: too many C++ applications broke because they used
iszero as a member function name.

I think I can guess which code base this is about. 8-) You really should
adopt a non-colliding naming scheme for your os:: wrapper functions.
This sidesteps this entire set of issues.

There really isn't a musl bug here, I think (but I'm not a musl


  parent reply	other threads:[~2022-06-29 16:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 15:49 Thomas Stüfe
2022-06-29 16:11 ` Markus Wichmann
2022-06-29 16:32   ` Thomas Stüfe
2022-06-29 16:15 ` Florian Weimer [this message]
2022-06-29 16:30   ` Thomas Stüfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).