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

[Fabiano Fidêncio]

On Wed, Nov 11, 2015 at 2:44 PM, Victor Toso <lists at victortoso.com> wrote:
> 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.

Yeah, that's exactly what I call "playing safe". I do prefer doing a
few more round of reviews than start changing the behavior of the
patches that have been tested and already have been used by people who
worked on this refactoring work.