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)

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.