g_atomic_* end up using G_STATIC_ASSERT, causing gcc 4.8 to yell due to
-Wunused-local-typedefs.
/usr/include/glib-2.0/glib/gmacros.h:162:53: error: typedef ‘_GStaticAssertCompileTimeAssertion_2’ locally defined but not used [-Werror=unused-local-typedefs]
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
Most of the uses of atomic operations were wrong. They were fixed as
well. If we are using atomic operations, reading the variable again
later for logging is not an option, we should use the return of the
atomic function used to fetch the variable.
This reverts commit 8a03376544.
The patch needs to be split up and the gdbus/ changes were bogus
compared to the original commit message.
Conflicts:
Makefile.am
Makefile.obexd
profiles/cyclingspeed/cyclingspeed.c
profiles/heartrate/heartrate.c
src/error.c
Instead of trying to include config.h in each file over the tree and
possibly forgetting to include it, give a "-include config.h" argument
to the compiler so it's guaranteed that a) it will be included for all
source files and b) it will be the first header included.
gdbus/ directory is left out, since it would break other projects using
it.
GUINT_TO_POINTER does not cast properly in older version of GLib (< 2.31)
causing the following errors:
cc1: warnings being treated as errors
gobex/gobex-apparam.c: In function ‘g_obex_apparam_set_bytes’:
gobex/gobex-apparam.c:176:38: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint8’:
gobex/gobex-apparam.c:243:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint16’:
gobex/gobex-apparam.c:261:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint32’:
gobex/gobex-apparam.c:282:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint64’:
gobex/gobex-apparam.c:303:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_string’:
gobex/gobex-apparam.c:324:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_bytes’:
gobex/gobex-apparam.c:342:43: error: cast to pointer from integer of
different size
make[1]: *** [gobex/gobex-apparam.o] Error 1
make: *** [all] Error 2
This introduce 2 new convenient functions: g_obex_header_get_apparam
which parses and decode an header into GObexApparam and
gobex_header_new_apparam that encode GObexApparam into GObexHeader.
GObexApparam abstract the handling of application parameter tags, it
can be used to read/parse application parameter header data using
g_obex_apparam_get_* functions or to generate the data using
g_obex_apparam_set_*.
If callback is provided in g_obex_cancel_transfer() current complete
callback will be replaced by the new one and user will be informed
when abort completes.
ENOSYS correspond to function not implemented which is exactly what the
OBEX error code means.
Also since EINVAL means invalid argument that now map to OBEX bad request
This patch create a map between posix errors code and OBEX response
opcode and use it to generate a proper response in case a transfer
failed instead of always responding with internal error.
GOEP 2.0 test specification forbids the server to include SRM headers in
CONNECT response:
"3.16 TP/SRM/BI-03-C Process an OBEX CONNECT request (incorrectly)
containing a SRM header:
• Expected Outcome
Pass Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT responds with a SUCCESS without a SRM header.
– OBEX/L2CAP channel is established.
Fail Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT does not respond with a SUCCESS and/or includes a SRM header in the
response.
– OBEX/L2CAP channel is not established or OBEX/RFCOMM channel is
established."
This simplifies the applications so SRM setup phase became transparent
while using SOCK_SEQPACKET which is useful for GOEP 2.0 since in that
case we can only use SRM if the transport is L2CAP.
This also follows GOEP 2.0 Page 14 - 4.6 Using Single Response Mode:
"The Server cannot issue an enable request, but can only issue a
response to an enable request from the Client. SRM will remain in
effect for the duration of the operation that enabled it (PUT or GET)
...
SRM headers shall not be sent in CONNECT request or response packets."
and Page 22 - 5.4 Establishment of OBEX Connection:
"SRM headers shall not be sent in the Connect request or response
packets (note, this is to preserve backwards compatibility). SRM shall
be enabled through Put and Get operations only."
So only in case of PUT or GET requests SRM is automatically configured,
applications can still enable it manually for other operations by adding
the headers like before but it is not recommended.
Note that it would be a good practice to indicate SRM support by using
value 0x02, but since that should happens during CONNECT command it is
not done automatically for requests when acting as a client, server
responding to indicate requests will automatically add SRM headers though.
The previous approach searched the transfer pointer itself, assuming
that the transfers has not been modified if the pointer is in the list.
However the callback could have removed the transfer and registered
another one, which can eventually point to the same memory location.
This is solved by looking for the transfer id instead of the pointer.
OBEX spec says:
Only the first packet in the request needs to contain the Connection
Id header...
If a Connection Id header is received with an invalid connection
identifier, it is recommended that the operation be rejected with the
response code (0xD3) “Service Unavailable”.
Since not all requests packets need to contain Connection Id header we
should only try to validate it in case a header is received.
Reported by Hendrik Sattler <post@hendrik-sattler.de>
Since gobex maintain the connection id of the session it is more
convenient to check whether the incoming request connection matches
before calling the application handlers.
