From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30813 invoked from network); 29 Jun 2022 16:15:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2022 16:15:41 -0000 Received: (qmail 6030 invoked by uid 550); 29 Jun 2022 16:15:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 6007 invoked from network); 29 Jun 2022 16:15:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656519326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kp2eJG/1b0vTspVUwByuVc39M5YM2R6aFObYMshKBrs=; b=ToymDWggy4O41mk1XzwHSb648TU7IUJEesPAI7zVrjphThAgh9ptTlaCcPTfp76ZvvcX+f EW+WKaxjP5nYM90jDCeSxuFEPjWHtQF7x8HlqqowAIiemYJYdL08UEzQ0JIoUWNnOvUKLW rBbsV3cxBsvD3uq9TvZhrQ2ZAsTAsYw= X-MC-Unique: 47sW3h-vMRuEK5vpiR8mMg-1 From: Florian Weimer To: Thomas =?utf-8?Q?St=C3=BCfe?= Cc: musl@lists.openwall.com References: Date: Wed, 29 Jun 2022 18:15:21 +0200 In-Reply-To: ("Thomas =?utf-8?Q?St=C3=BCfe=22's?= message of "Wed, 29 Jun 2022 17:49:55 +0200") Message-ID: <87sfnn1m5i.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE * Thomas St=C3=BCfe: > Greetings, > > I have a small question about the way muslc implements the CPU_ALLOC and = CPU_FREE > macros.=20 > > 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