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.