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_ADSP_CUSTOM_MED,
	DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 27586 invoked from network); 29 Jun 2022 15:50:22 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2022 15:50:22 -0000
Received: (qmail 25835 invoked by uid 550); 29 Jun 2022 15:50:19 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 25799 invoked from network); 29 Jun 2022 15:50:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=+xjMaA1X78r14v2e7IHkB58ilDivh7RgUDMDb563wgM=;
        b=EMUQgYoDZI81mKcl7RwX+NKWMMpFIN5WhMG4qgCn7fV5w09YpyaFQ+JF2Lc26P3ivS
         7K6Dsi/kknNUvRlk5SCIcese7l975EmZQ0wIobHgA6NElcaZ6C5uvLA1PDSDXX3a1xs8
         0xAUh4coAu4DYcRdf9AV0JLpGco4JU7vLPOHH3pQ5PS3yCLrKcoaZ+gcsDYcs4k5WYb0
         +ZA3eoOvG1cHB9wwlQ6hH3vMzewOlPk186tgZRm62v2ePYrNRPtdwTQvKqQY5ps/jM3p
         001BwK+6KZE1XEl7ozp4ll0Z3CsSr8ovqbnyXA8ld74bOZyzDtZASy83N5+urtPhlLW6
         ssfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=+xjMaA1X78r14v2e7IHkB58ilDivh7RgUDMDb563wgM=;
        b=EM7oXX5Yj6bl1efKdWrXfZ7uy5nyValXLXPTeyUXBrxNwrCUhW10pkrZGdjjTIg1Sb
         giOl2+y77m8chnlQcIvxePThw6IXfbTS48EqNL9dL29E3e2XUuPgDt+0wgazxizIZEsw
         pvtqrqaqR6jTLZNL4+70rdB5kCrk1XaZSV9aKloxGJJ3InhYj0Mng3/FfcSEOmaUt0N7
         qWGcxp1DeuBJSbY9vawvkGuNLDin/IvXRFI0l58hA9h/tyGwU0WFQG9/6t6XmkS2sk7A
         ytvKvqCd7Uu15D6mhjDALW2MWOCxGA5+nn1F3xYpqeYz/GhNGzcjhR4Doa67WbSXoqWk
         9byQ==
X-Gm-Message-State: AJIora+VXTyGMipkXF1D0SrtQDq8Vs/96sCirc6r1DQmsQzr756KlOdn
	Nl5oWAJATSobLr1/HUucS3rEjhnhqD8y+D+0d7Ik3k5I9lZmawqx
X-Google-Smtp-Source: AGRyM1v43A6CaClS99JKHsees6f3z65RWRodm7KU4bqq6umlxCj+O+lAKRsV844Iu6QpZixCt09jTkHalMYiLhr44ik=
X-Received: by 2002:a17:903:3286:b0:16a:b0c:336 with SMTP id
 jh6-20020a170903328600b0016a0b0c0336mr11082851plb.79.1656517806300; Wed, 29
 Jun 2022 08:50:06 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?Q?Thomas_St=C3=BCfe?= <thomas.stuefe@gmail.com>
Date: Wed, 29 Jun 2022 17:49:55 +0200
Message-ID: <CAA-vtUxnzh-OwpGaZd=D=i_KbYWRu-AWn6uJhQa5RGKg-dxd7g@mail.gmail.com>
To: musl@lists.openwall.com
Content-Type: multipart/alternative; boundary="00000000000068a1d705e2981bb9"
Subject: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE

--00000000000068a1d705e2981bb9
Content-Type: text/plain; charset="UTF-8"

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++.

I realize this is not a big issue. But would it not be safer to do as the
glibc does in this case?

Thank you,

Thomas

--00000000000068a1d705e2981bb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Greetings,</div><div><br></div><div>I have a small qu=
estion about the way muslc implements the CPU_ALLOC and CPU_FREE macros.=C2=
=A0</div><div><br></div><div>I see them defined in sched.h as:</div><div><b=
r></div>#define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))<br>=
#define CPU_FREE(set) free(set)<br><div><br></div><div>whereas the glibc de=
fines them as calls to functions __sched_cpu_alloc() and=C2=A0__sched_cpufr=
ee():</div><div><br></div><div>#define __CPU_ALLOC(count) __sched_cpualloc =
(count)<br></div><div>#define __CPU_FREE(cpuset) __sched_cpufree (cpuset)<b=
r></div><div><br></div><div>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 &quot;free&quot; or &quot;calloc&quot; (okay, l=
ess likely) these get called instead. Could also be a class local method in=
 C++.</div><div><br></div><div>I realize this is not a big issue. But would=
 it not be safer to do as the glibc does in this case?</div><div><br></div>=
<div>Thank you,</div><div><br></div><div>Thomas</div><div><br></div><div><b=
r></div></div>

--00000000000068a1d705e2981bb9--