mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
@ 2022-06-29 15:49 Thomas Stüfe
  2022-06-29 16:11 ` Markus Wichmann
  2022-06-29 16:15 ` Florian Weimer
  0 siblings, 2 replies; 5+ messages in thread
From: Thomas Stüfe @ 2022-06-29 15:49 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1131 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
  2022-06-29 15:49 [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE Thomas Stüfe
@ 2022-06-29 16:11 ` Markus Wichmann
  2022-06-29 16:32   ` Thomas Stüfe
  2022-06-29 16:15 ` Florian Weimer
  1 sibling, 1 reply; 5+ messages in thread
From: Markus Wichmann @ 2022-06-29 16:11 UTC (permalink / raw)
  To: musl

On Wed, Jun 29, 2022 at 05:49:55PM +0200, Thomas Stüfe 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 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++.
>

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 the
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
  2022-06-29 15:49 [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE Thomas Stüfe
  2022-06-29 16:11 ` Markus Wichmann
@ 2022-06-29 16:15 ` Florian Weimer
  2022-06-29 16:30   ` Thomas Stüfe
  1 sibling, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2022-06-29 16:15 UTC (permalink / raw)
  To: Thomas Stüfe; +Cc: musl

* 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
  2022-06-29 16:15 ` Florian Weimer
@ 2022-06-29 16:30   ` Thomas Stüfe
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Stüfe @ 2022-06-29 16:30 UTC (permalink / raw)
  To: Florian Weimer; +Cc: musl

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Wed, Jun 29, 2022 at 6:15 PM Florian Weimer <fweimer@redhat.com> wrote:

> * 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.
>
>
:-) I guess you guess right.

Yes, the JVM crashes on Alpine because of ::malloc() -> os::free()
disbalance: https://bugs.openjdk.org/browse/JDK-8289477

And you are absolutely right. We should change the naming scheme.


> There really isn't a musl bug here, I think (but I'm not a musl
> developer).
>
>
I think so too now.


> Thanks,
> Florian
>
>
Thank you, Thomas

[-- Attachment #2: Type: text/html, Size: 2891 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE
  2022-06-29 16:11 ` Markus Wichmann
@ 2022-06-29 16:32   ` Thomas Stüfe
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Stüfe @ 2022-06-29 16:32 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

On Wed, Jun 29, 2022 at 6:11 PM Markus Wichmann <nullplan@gmx.net> wrote:

> On Wed, Jun 29, 2022 at 05:49:55PM +0200, Thomas Stüfe 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 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++.
> >
>
> 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 the
> > 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
>

Thanks a lot for the quick response, Markus.

I'm with the OpenJDK project, and the VM crashes on Alpine because of this
issue (https://bugs.openjdk.org/browse/JDK-8289477). But I don't think
muslc does anything wrong, and the fix is very simple (now that I know what
happens).

Cheers, Thomas

[-- Attachment #2: Type: text/html, Size: 2545 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-06-29 16:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-29 15:49 [musl] Question about calloc, free in CPU_ALLOC and CPU_FREE Thomas Stüfe
2022-06-29 16:11 ` Markus Wichmann
2022-06-29 16:32   ` Thomas Stüfe
2022-06-29 16:15 ` Florian Weimer
2022-06-29 16:30   ` Thomas Stüfe

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).