From: "Gix, Brian" <brian.gix@intel.com>
To: "michal.lowas-rzechonek@silvair.com"
<michal.lowas-rzechonek@silvair.com>,
"denkenz@gmail.com" <denkenz@gmail.com>
Cc: "marcel@holtmann.org" <marcel@holtmann.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ v2] mesh: Use node uuids as storage directory names
Date: Wed, 8 May 2019 14:23:22 +0000 [thread overview]
Message-ID: <1557325399.31289.16.camel@intel.com> (raw)
In-Reply-To: <20190508043901.bcueazjay3nm6cya@kynes>
Hi Michal,
On Wed, 2019-05-08 at 06:39 +0200, michal.lowas-rzechonek@silvair.com wrote:
> Hi Denis, Brian,
>
> On 05/07, Denis Kenzior wrote:
> > > > + if (asprintf(&cfg, "%s/%s/node.json", dir_name,
> > > > + entry->d_name) < 0)
> > > > + continue;
> > >
> > > With ELL, we do not use asprintf. Every dynamic allocation must map
> > > back to l_malloc, which performs an abort() if a memory allocation
> > > fails. So this should be re-coded as a malloc of the desired size,
> > > and then use snprintf, using the malloc'd length as N.
> >
> > ...or use l_strdup_printf. Which is actually asprintf underneath...
> > ;)
>
> Will do, thanks for the tip!
>
> Incidentally, are you aware why 'main' bluez aims to drop glib?
ELL is a space efficient library tailored for services that can be targeted at embedded systems, and suffers
from less "Size Bloat" than GLIB. That is the main reason, and has been championed by Marcel, who might have
more to say about it.
prev parent reply other threads:[~2019-05-08 14:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 7:13 [PATCH BlueZ v2] mesh: Use node uuids as storage directory names Michał Lowas-Rzechonek
2019-05-07 18:14 ` Stotland, Inga
2019-05-07 20:41 ` Gix, Brian
2019-05-07 20:55 ` Denis Kenzior
2019-05-08 4:39 ` michal.lowas-rzechonek
2019-05-08 14:23 ` Gix, Brian [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1557325399.31289.16.camel@intel.com \
--to=brian.gix@intel.com \
--cc=denkenz@gmail.com \
--cc=inga.stotland@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=michal.lowas-rzechonek@silvair.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).