The CUPS backend would be aborting when scanning for a printer that's
not in bluetoothd known devices. Fixes both bugs I found in my testing.
Cheers
Hi Bastien,
> > > The CUPS backend would be aborting when scanning for a printer that's
> > > not in bluetoothd known devices. Fixes both bugs I found in my testing.
> >
> > can we at least try to keep the coding style. I don't really know what
> > is so hard about it.
>
> Thanks for all the love.
you know that I am picky with this ;)
> Updated patches attached.
Patches have been applied. Thanks.
Regards
Marcel
On Tue, 2009-08-11 at 15:02 -0700, Marcel Holtmann wrote:
> Hi Bastien,
>
> > The CUPS backend would be aborting when scanning for a printer that's
> > not in bluetoothd known devices. Fixes both bugs I found in my testing.
>
> can we at least try to keep the coding style. I don't really know what
> is so hard about it.
Thanks for all the love.
Updated patches attached.
Hi Bastien,
> The CUPS backend would be aborting when scanning for a printer that's
> not in bluetoothd known devices. Fixes both bugs I found in my testing.
can we at least try to keep the coding style. I don't really know what
is so hard about it.
dbus_message_iter_get_basic(&iter, &name);
+ if (name == NULL ||
+ strcmp(name, "Discovering") != 0)
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
dbus_message_iter_next(&iter);
The NULL check and strcmp can go on the same line here.
if (!reply)
return;
- } else {
- if (dbus_message_get_args(reply, NULL, DBUS_TYPE_OBJECT_PATH, &object_path, DBUS_TYPE_INVALID) == FALSE)
- return;
+ }
+ if (dbus_message_get_args(reply, NULL, DBUS_TYPE_OBJECT_PATH, &object_path, DBUS_TYPE_INVALID) == FALSE) {
+ return;
}
I know that the previous one exceeded the 80 char limit, but no need to
keep it.
Regards
Marcel