Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA-vtUxnzh-OwpGaZd=D=i_KbYWRu-AWn6uJhQa5RGKg-dxd7g@mail.gmail.com>
Date: Wed, 29 Jun 2022 17:49:55 +0200
From: Thomas Stüfe <thomas.stuefe@...il.com>
To: musl@...ts.openwall.com
Subject: Question about calloc, free in CPU_ALLOC and CPU_FREE

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

Content of type "text/html" skipped

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.