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.
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.
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.
A user callback could potentially do things like g_obex_cancel_request
or g_obex_unref while we are inside the IO watch callback. It is
therefore important to ensure that we are in a consistent state when the
user callback returns.
To use the replacement for g_slist_free_full() both compat.h and
glib-helper.h need to be included.
Fixes:
gobex/gobex.c:911: error: implicit declaration of function 'g_slist_free_full'
tools/obex-server-tool.c:344: error: implicit declaration of function ‘g_slist_free_full’
Fixes the following issue seen on debian unstable:
gobex/gobex.c: In function 'handle_request':
gobex/gobex.c:646:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
