Does Musl offer a thread-safe and non-dynamically allocating version of strsignal?

Does Musl offer a thread-safe and non-dynamically allocating version of strsignal?

[Steven Stewart-Gallus]

Hello,

I am currently using Musl Libc to test the portability of some of my
code and while porting my code over I found a small deficiency.  This
annoyance is not a big deal as I am not currently using Musl in
production but I thought I should let you know anyways so that Musl
can be improved and that other people might benefit.  Currently with
GLibc I use the deprecated sys_siglist static array of string names
for signals to get the names of signals (this might actually be the
signal that a process I am monitoring receives and not just the kind
the current process's libc knows about) in a thread safe way without
the complications of dynamic memory allocation.  Obviously, I could
just use the strsignal function but I do not know if strsignal is
thread safe or dynamically allocates memory.  Does Musl offer a
thread-safe and non-dynamically allocating version of strsignal?

Thank you,
Steven Stewart-Gallus

Re: Does Musl offer a thread-safe and non-dynamically allocating version of strsignal?

[Justin Cormack]

On 7 March 2015 at 21:51, Steven Stewart-Gallus
<sstewartgallus00@mylangara.bc.ca> wrote:
> Hello,
>
> I am currently using Musl Libc to test the portability of some of my
> code and while porting my code over I found a small deficiency.  This
> annoyance is not a big deal as I am not currently using Musl in
> production but I thought I should let you know anyways so that Musl
> can be improved and that other people might benefit.  Currently with
> GLibc I use the deprecated sys_siglist static array of string names
> for signals to get the names of signals (this might actually be the
> signal that a process I am monitoring receives and not just the kind
> the current process's libc knows about) in a thread safe way without
> the complications of dynamic memory allocation.  Obviously, I could
> just use the strsignal function but I do not know if strsignal is
> thread safe or dynamically allocates memory.  Does Musl offer a
> thread-safe and non-dynamically allocating version of strsignal?

One of the really nice things about Musl is that you can easily read
the code, and find your way around it. Looking at
src/string/strsignal.c, there are no allocations and all the names are
const, so you should be fine.

Justin

Re: Does Musl offer a thread-safe and non-dynamically allocating version of strsignal?

[Rich Felker]

On Sat, Mar 07, 2015 at 09:51:24PM +0000, Steven Stewart-Gallus wrote:
> Hello,
> 
> I am currently using Musl Libc to test the portability of some of my
> code and while porting my code over I found a small deficiency.  This
> annoyance is not a big deal as I am not currently using Musl in
> production but I thought I should let you know anyways so that Musl
> can be improved and that other people might benefit.  Currently with
> GLibc I use the deprecated sys_siglist static array of string names
> for signals to get the names of signals (this might actually be the
> signal that a process I am monitoring receives and not just the kind
> the current process's libc knows about) in a thread safe way without
> the complications of dynamic memory allocation.  Obviously, I could
> just use the strsignal function but I do not know if strsignal is
> thread safe or dynamically allocates memory.  Does Musl offer a
> thread-safe and non-dynamically allocating version of strsignal?

Both strsignal and strerror in musl return immutable strings, and are
fully thread-safe.

Rich