[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sfnn1m5i.fsf@oldenburg.str.redhat.com>
Date: Wed, 29 Jun 2022 18:15:21 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Thomas Stüfe <thomas.stuefe@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Question about calloc, free in CPU_ALLOC and CPU_FREE
* 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
developer).
Thanks,
Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
