im.pidgin.pidgin: 040eda39d04e967c5904d63394086090b449dd17

[Will Thompson]

On Fri, Feb 01, 2008 at 07:39:08PM -0500, John Bailey wrote:
> resiak at soc.pidgin.im wrote:
> > ChangeLog: 
> > 
> > Passing NULL to msn_user_set_friendly_name explodes, and msn_user_new is called
> > by session.c with friendly_name unconditionally NULL, so I have no idea why
> > this ever worked.
> >
> > ============================================================
> > --- libpurple/protocols/msnp9/user.c	92a67c2d9914c87de46146f76f97a1bd8fed8258
> > +++ libpurple/protocols/msnp9/user.c	58a59bd522734e7d219a276ce4ee6311a2982c42
> > @@ -36,7 +36,8 @@ msn_user_new(MsnUserList *userlist, cons
> >  	user->userlist = userlist;
> >  
> >  	msn_user_set_passport(user, passport);
> > -	msn_user_set_friendly_name(user, friendly_name);
> > +	if (friendly_name != NULL)
> > +		msn_user_set_friendly_name(user, friendly_name);
> >  
> >  	return user;
> >  }
> 
> Shouldn't the NULL check be in msn_user_set_friendly_name() so that the function
> just silently fails instead of crashing?

Hmm, I could have sworn I'd checked and found there was a
g_return_if_fail in it, but there isn't.  I didn't know whether calling
set_friendly_name with NULL was meant to be valid or not, and no msnp9
people were around.

Looking at the other uses of set_friendly_name, I don't think friendly
is ever meant to be NULL; perhaps the NULL check in msn_user_new should
stay, and a g_return_if_fail should be added to set_friendly_name ?

-- 
Will
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080202/7cffadc8/attachment.sig>