All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Paulo Alcantara <paulo.alcantara@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org,
	Claudio Takahasi <claudio.takahasi@openbossa.org>
Subject: Re: [PATCH BlueZ v2 2/2] core: Fix creating device from "primary" file
Date: Tue, 22 May 2012 11:00:02 +0300	[thread overview]
Message-ID: <20120522080002.GA9688@x220> (raw)
In-Reply-To: <1337633316-4992-3-git-send-email-paulo.alcantara@openbossa.org>

Hi,

On Mon, May 21, 2012, Paulo Alcantara wrote:
> From: Claudio Takahasi <claudio.takahasi@openbossa.org>
> 
> This patch removes the hard-coded address type for the BLE device
> created from the storage.
> ---
>  src/adapter.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/adapter.c b/src/adapter.c
> index dafe595..1ca21e6 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -1940,13 +1940,17 @@ static void create_stored_device_from_primary(char *key, char *value,
>  	struct btd_adapter *adapter = user_data;
>  	struct btd_device *device;
>  	GSList *services, *uuids, *l;
> +	char address[18];
> +	uint8_t bdaddr_type;
> +
> +	if (sscanf(key, "%17s#%hhu", address, &bdaddr_type) < 2)
> +		bdaddr_type = BDADDR_LE_PUBLIC;

That's not safe. What if sscanf returns 0 or a negative value? In that
case the address variable will remain uninitialized (which is why you
should have just followed my suggestion of testing for < 1 and returning
in such a case).

Thinking more about this situation I'm not sure if it's any better to
allow creation of old entries since you won't be able to remove them
anyway: the remove code looks for a bdaddr#type key which won't exist
and adding code to look for both types of keys is just bloating the code
base for a minor benefit.

So maybe your initial patch of failing in the case of sscanf returning < 2
is good enough after all.

Johan

  reply	other threads:[~2012-05-22  8:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 20:57 [PATCH BlueZ 0/2] Store address type on storage Paulo Alcantara
2012-05-18 20:57 ` [PATCH BlueZ 1/2] storage: Store BLE address type in "primary" file Paulo Alcantara
2012-05-19  6:41   ` Johan Hedberg
2012-05-21 20:52     ` Paulo Alcantara
2012-05-18 20:57 ` [PATCH BlueZ 2/2] core: Fix creating device from " Paulo Alcantara
2012-05-19  6:43   ` Johan Hedberg
2012-05-21 20:56     ` Paulo Alcantara
2012-05-21 20:48 ` [PATCH BlueZ v2 0/2] Address type in keys on storage filesystem Paulo Alcantara
2012-05-21 20:48   ` [PATCH BlueZ v2 1/2] storage: Store BLE address type in "primary" file Paulo Alcantara
2012-05-22  8:05     ` Johan Hedberg
2012-05-22 17:08       ` Paulo Alcantara
2012-05-21 20:48   ` [PATCH BlueZ v2 2/2] core: Fix creating device from " Paulo Alcantara
2012-05-22  8:00     ` Johan Hedberg [this message]
2012-05-22 17:33       ` Claudio Takahasi
2012-05-22 19:45 ` [PATCH BlueZ v3 0/3] Store address type on storage Paulo Alcantara
2012-05-22 19:45   ` [PATCH BlueZ v3 1/3] storage: Store BLE address type in "primary" file Paulo Alcantara
2012-05-22 19:45   ` [PATCH BlueZ v3 2/3] core: Fix creating device from " Paulo Alcantara
2012-05-22 19:45   ` [PATCH BlueZ v3 3/3] core: Fix removing device services " Paulo Alcantara
2012-05-23 14:05   ` [PATCH BlueZ v3 0/3] Store address type on storage Johan Hedberg

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=20120522080002.GA9688@x220 \
    --to=johan.hedberg@gmail.com \
    --cc=claudio.takahasi@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=paulo.alcantara@openbossa.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.