From: "Thomas Stüfe" <firstname.lastname@example.org>
Subject: Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
Date: Wed, 29 Jun 2022 18:32:30 +0200 [thread overview]
Message-ID: <CAA-vtUw5aQ-xAdChj-Fs7XiXEA0SoW9jP5in9F6KEHpfzJaWRw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]
On Wed, Jun 29, 2022 at 6:11 PM Markus Wichmann <email@example.com> wrote:
> On Wed, Jun 29, 2022 at 05:49:55PM +0200, Thomas Stüfe wrote:
> > 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
> > "free" or "calloc" (okay, less likely) these get called instead. Could
> > be a class local method in C++.
> That would be invalid. calloc() and free() are names defined in the C
> standard, so no user defined macro or function can have those names.
> I don't know about you point about C++, though. Could be conceivably
> worked around by using the :: operator, but that is only valid in C++,
> so we'd have to #ifdef it.
> > I realize this is not a big issue. But would it not be safer to do as the
> > glibc does in this case?
> Not really; if someone wants to use reserved names, there is little
> reason to presume that "calloc" is any safer than "__sched_cpualloc".
> > Thank you,
> > Thomas
Thanks a lot for the quick response, Markus.
I'm with the OpenJDK project, and the VM crashes on Alpine because of this
issue (https://bugs.openjdk.org/browse/JDK-8289477). But I don't think
muslc does anything wrong, and the fix is very simple (now that I know what
[-- Attachment #2: Type: text/html, Size: 2545 bytes --]
next prev parent reply other threads:[~2022-06-29 16:32 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 [this message]
2022-06-29 16:15 ` Florian Weimer
2022-06-29 16:30 ` Thomas Stüfe
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).