will at willthompson.co.uk
Fri Feb 1 19:49:33 EST 2008
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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel