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

[Victor Toso]

On Wed, Nov 11, 2015 at 02:18:34PM +0100, Fabiano Fidêncio wrote:
> 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!

Too bad, as we (you) are reviewing this patches now and will need to do
it again later on for the whole code, exactly because the behavior is
different.