On Wed, Nov 11, 2015 at 2:44 PM, Victor Toso <lists@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
>> > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxx>
>> >
>> > ---
>> > 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@xxxxxxxxxxxxxxxxxxxxx
>> > 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.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel