[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK4o1WwhtruiVU4+a9jB3e1dpz=JJOnaS49f11kpOJEQaZRByA@mail.gmail.com>
Date: Sat, 7 Mar 2015 22:09:32 +0000
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: Does Musl offer a thread-safe and non-dynamically
allocating version of strsignal?
On 7 March 2015 at 21:51, Steven Stewart-Gallus
<sstewartgallus00@...angara.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
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.
