bdaddr flipping everywhere

[GoogleCodeExporter]

issue opened on r2351

this isn't a bug or anything, but just something I noticed and want to have a 
discussion about.

I noticed that as soon as any sort of bdaddr is transmitted over HCI, it is 
immediately flipped before being used for anything else.

Before I started using btstack, I was writing my own stack. I always kept the 
bdaddr in memory in the same order as given in all of the packets. The only 
place where it is flipped is a dedicated function designed solely to format the 
bdaddr for debugging.

However, in btstack, it seems like it is always flipped, even for comparison 
operations and storage

This seems unnecessary, and often I see the flipping performed twice. For 
example, hci_cmd.c around line 104.

I don't like it, it causes confusion and gives room for possible errors.

For example, sending a link_key_reply in response to a link_key_request, if I 
don't perform the flip, then the reply would be incorrect. I don't know that 
the flipping is a requirement at all, I don't see any documentation on it

I am guessing this is because PowerPC is big-endian and you are an Apple fanboy 
:-P (just joking)

Anyways, it is my opinion that the flipping should only be performed during 
string formatting, and never done anywhere else.

I do realize that if you implement a change to remove the flipping, most of the 
memory databases will become useless after updating.

(my application involves transfering bdaddr over USB, it is wise for me to 
avoid flipping anywhere)

Original issue reported on code.google.com by frank.zhao.main@gmail.com on 5 Feb 2014 at 8:01

[GoogleCodeExporter]

well, it doesn't cause confusion. Bluetooth uses little endian and BTstack uses 
big-endian, without any shortcuts.

You're not so wrong about fan-boyism. I grew up on big endian architectures: 
6502, 68000, PowerPC and mostly use Apple hardware (Mac Book Airs, iPhones, 
iPods, iPads). 

That being said, you make a valid point. BTstack should store the bd_addr in 
the host endianess to be consistent, although a clear case could be made to 
just store it in little endian. I think that's a good idea but will defer that 
after BTstack testing - it's really dangerous especially as the Security 
Manager does funny stuff to generate private (non-)resolvable addresses.

Original comment by matthias.ringwald@gmail.com on 6 Feb 2014 at 1:15

• Changed state: Accepted