public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Ronny L Nilsson <bb@arbetsmyra.dyndns.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] bccmd patch, find connection handle by bdaddr
Date: Tue, 9 Aug 2005 16:36:11 +0200	[thread overview]
Message-ID: <20050809144239.29D538AD@arbetsmyra.dyndns.org> (raw)
In-Reply-To: <1123522342.7751.49.camel@pegasus>


> > them small and separate. The one attached makes bccmd able to find
> > a ACL connection handle itself, instead of require user to provide
> > it on commandline. I'm using it in a cmd_keylen() patch (which I
> > post when this one gets applied).


> please follow our coding style. This little code snippet breaks it 

Hi
I'm refreshing myself on "Documentation/CodingStyle" now and will make 
some adjustments.


> and it includes a free(NULL) bug.

That's actually ok. According to both K&R and the GNU manuals it is 
fully legal. The C-lib checks for NULL and in that case does nothing. I 
can add an extra check though if you want the double safetey. B.T.W I 
saw your most resent commit on  libs/src/bluetooth.c  contains a 
bt_malloc(). Is that to be used instead from now on?


> The handle is uint32_t 

Really? Strange. The kernel #includes define the handle as an uint16_t 
only (struct hci_conn). And according to the v2.0 spec only the least 
12-bits is actually used. I then used a signed 32 to be able to do a 
return of both those unsigned 12/16 bits and a -1 error indicator. 
Perhaps I've missed something, where does the remaining data come from?


> and you should keep the endian conversion in mind.

The handle returned from ioctl() is in host byte order already since 
the kernel makes a conversion. What to do next with it one can discuss. 
Especially when it comes to be used with "complex" lengthed Varid's 
it's easy to make mistakes due to quite odd BCCMD protocol byte 
ordering (where 32-bits are neither of big/little-endian). I was 
thinking it's probably easiest to leave the handle as-is for all of 
those many:
	buf[0] = handle & 0xff;
	buf[1] = handle >> 8;
which complex BCCMD require. I'm open to suggestions though.


Regards
/Ronny





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2005-08-09 14:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-08 11:55 [Bluez-devel] bccmd patch, find connection handle by bdaddr Ronny L Nilsson
2005-08-08 17:32 ` Marcel Holtmann
2005-08-09 14:36   ` Ronny L Nilsson [this message]
2005-08-16 15:28     ` Marcel Holtmann

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=20050809144239.29D538AD@arbetsmyra.dyndns.org \
    --to=bb@arbetsmyra.dyndns.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /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