[Spice-devel] [PATCH 04/11] worker: remove cursor channel asserts

[Fabiano Fidêncio]

On Wed, Nov 11, 2015 at 1:20 PM, Frediano Ziglio <fziglio at redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lureau at gmail.com>
>
> ---
>  server/cursor-channel.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/server/cursor-channel.c b/server/cursor-channel.c
> index aafc807..794dcf3 100644
> --- a/server/cursor-channel.c
> +++ b/server/cursor-channel.c
> @@ -223,7 +223,7 @@ static void put_cursor_pipe_item(CursorChannelClient *ccc, CursorPipeItem *pipe_
>          return;
>      }
>
> -    spice_assert(!pipe_item_is_linked(&pipe_item->base));
> +    spice_return_if_fail(!pipe_item_is_linked(&pipe_item->base));
>
>      cursor_item_unref(pipe_item->cursor_item);
>      free(pipe_item);
> @@ -281,7 +281,7 @@ static void red_marshall_cursor_init(RedChannelClient *rcc, SpiceMarshaller *bas
>      SpiceMsgCursorInit msg;
>      AddBufInfo info;
>
> -    spice_assert(rcc);
> +    spice_return_if_fail(rcc);
>      cursor_channel = SPICE_CONTAINEROF(rcc->channel, CursorChannel, common.base);
>
>      red_channel_client_init_send_data(rcc, SPICE_MSG_CURSOR_INIT, NULL);
> @@ -414,7 +414,7 @@ static void cursor_channel_release_item(RedChannelClient *rcc, PipeItem *item, i
>  {
>      CursorChannelClient *ccc = RCC_TO_CCC(rcc);
>
> -    spice_assert(item);
> +    spice_return_if_fail(item);
>
>      if (item_pushed) {
>          cursor_channel_client_release_item_after_push(ccc, item);
> --
> 2.4.3
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

Please, use explicit checks!
Toso has a good point, but I would prefer to not introduce the glib
functions now, mainly because the behavior is not exactly the same.

I would prefer play safe now and just keep patches as they are and
then, in the near future do a big sed. I do believe it would be better
to understand possible problems that can show up due to different
behavior (mainly in patches bigger than this one) ...

ACK!