We have a number of functions in mozilla/Endian.h for doing endianness
conversions, and these functions should be used instead of hand-rolled
functions. Using those functions in the bluetooth code makes the code
clearer and more portable (ReadLittleEndianUint16 won't do the right
thing if we're running on a big-endian processor, for instance).
Endian.h is also careful to avoid assumptions about memory alignment,
which utility functions like ReadLittleEndianUint16 don't do.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This patch moves the code for registering and unregistering the
Handsfree backend module into the Handsfree manager. The respective
code in the backend itself has been removed.
The new design allows for a strict separation between Setup module
and Handsfree module.
This patch moves the code for registering and unregistering the
GATT backend module into the GATT manager. The respective code in
the backend itself has been removed.
The new design allows for a strict separation between Setup module
and GATT module.
This patch moves the code for registering and unregistering the
AVRCP backend module into the AVRCP manager. The respective code
in the backend itself has been removed.
The new design allows for a strict separation between Setup module
and AVRCP module.
This patch moves the code for registering and unregistering the
A2DP backend module into the A2DP manager. The respective code in
the backend itself has been removed.
The new design allows for a strict separation between Setup module
and A2DP module.
This patch moves |BluetoothAddress| to BluetoothCommon.h, where it is
available for general use. New utility function convert between strings
and addresses. A new hash-key class allowes for using |BluetoothAddress|
as the key in a hash table.
This patch moves |BluetoothAddress| to BluetoothCommon.h, where it is
available for general use. New utility function convert between strings
and addresses. A new hash-key class allowes for using |BluetoothAddress|
as the key in a hash table.
This patch converts all public interfaces of the Bluetooth backend code
to take UUIDs as |BluetoothUuid|. The code currently uses a mixture of
|BluetoothUuid| and arrays/pointers.
The current IPC parsing code is incorrect. AVRCP remote features are
specified as bitmask, but the current IPC code treats them as values.
This patch fixes this.
Except the d'tors, we usually don't call any interfaces of the Bluetooth
backend interfaces. All methods are overriden in child classes.
This patch move the methods from the interface's header file to the source
file. Only the result handlers' d'tors are located in the header, as they
can be inlined.