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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30269 invoked from network); 29 Jun 2022 16:11:52 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2022 16:11:52 -0000 Received: (qmail 3501 invoked by uid 550); 29 Jun 2022 16:11:49 -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 3469 invoked from network); 29 Jun 2022 16:11:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1656519097; bh=vOQ1NR0VHcmuJr4CG6aSQsY6tNhnPhvBjkxOJt0/CCI=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=dJmWjQiURCsW5jkKZ0OUM5YSHTj0cVv+fdw6jTW843wBH88o3f2oE08tqJRP3g7+B eu83rGLEv8ZZsbnnE7i7c8zU+yoGKQ03KVFHKSggey2FB0/I4i3/MUleU1OoS8zBpM AZzA/B3XLJ3aLKwv/XopI0AqnwMe+sMMgtEWGBaA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 29 Jun 2022 18:11:36 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220629161136.GD2408@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:dLeiEHgmOdVEUP36FljM4nwvPnJpIRFj9EwLXd2Rjb/WSzCCBdX Y4eD1B/fWeecrSDckxnv/JvSAkV4IIyxYdnDxHY+2z92fg4qBvIv0nng5YNVidC6Mkwi+rs juxHgp4MybNLZ0/2nCb9vIyaKAX2SDNXfVt2IGkIVvG8uIoUJyKazpCCn0uBUPGlz1EePvN SYdwmTfhZoDgKdrj11b0w== X-UI-Out-Filterresults: notjunk:1;V03:K0:IZ+yQYHD5tM=:kyBL+HPBHdsXcIQlkyAQ28 CX1sqRINEcLx6Ke+K4YVC+mDt6PJmL0k8lPHzGtyLBsMLwlpQwdhyWkzC0paT+vtyAumO4hYd M1FRDvIUzBqy9qLzai7yHObOGdpFj/hPK1TbIzqpWhkt/+EBDxpkP7iju8WbEBVGhPA448Eb8 X7qq015QsF18Yp9CXCny0l64a8+aVcweyDOL/nUUslBCDXd7YslV5CWU9yrX2JtQrA/MvkhqR UWS9jdBGzJSR2rmdyD6xj0gLUBQGDxfvO0WRVY4598u47SRg4XRHTrApEzERSD5gSvA2IEROP Bnt6k1OcqASGuQd1B4SSLqudK4fR6rpKhJndWjtcYTDCnDSPUTV7/BZEO4drs+IaSmkZPwOtf inO7H2S0tNVOIiXG2hqSklsB0OAPpyXxU8AELR5sMhNL/XL2nBxzIWC9jGoZ5CG2DmgT52i/+ IGoAhHLQnxVlqPg6LgtIoXEi7hSOME4aajc4dOqj1UEeAJwM/n8WEQu9Nq9o+Crzc55xdqYRT Y3f+D0n0Ju8KDVVYSUXOL0tlcA3UhS4GUREUGZIrLE7zOdqX1G4QHpvottSdfpaYZI4ap2y+G N1dboTPejhhVakwLazDg8O7dJ0FfgPzzKSJZ8UTBMBF8OdJdH2A5rGybPqHbC7X4ftNV0NnE4 oby2bABNrsfa1Hb6itvqVfyFNUSiLxd4tqA8w+SwQNyeKFkH5YBYuQTCBX00yVZAaMm/X4qms XbJMSc9QgPRvDBzGeLt594dQmmF7Qq0iWAVqIb/bJP/R4f7SQl12bWTswcSilWe4hyeUXgh9w gGp+py0v0f8Ae7HXubVwKdh65dtu3sLUcUX/gbFeA74iI4mjkbC21wR9flSssGKZ6/vA8DWmS C7zleL8oztyfGW58HxUWBkPZIaU2Eia0RX9oTeb+wmwWQD9hV9TpK8BO7LjuNwyCLG2HvLoY/ 9cjA/bC7G020tYOLXQUox7fB7E8rWv4U/5SCMG3EVcSGej1zSfW1vXoZeRpUsuzDRSDcBPRZL gCEHf7J6ZQWQ5G4Kmyu1BxYwXah01EUCJHghKpu0pLDpZgQmztEKWjrn/z7biLJTJSiV1gTkf P81ZdYVZFmHcM4HJt61esphjzfpWC75k7lpWFGbNo4ZHCBcefUiq60gKQ== Subject: Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE On Wed, Jun 29, 2022 at 05:49:55PM +0200, Thomas St=FCfe 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 get= s > inlined directly into the calling code. If that calling code has a funct= ion > "free" or "calloc" (okay, less likely) these get called instead. Could a= lso > 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 th= e > 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 Ciao, Markus