ayatana-commits team mailing list archive

[Ted Gould <ted@xxxxxxxx>]

On Thu, 2009-08-27 at 11:33 +0000, Neil J. Patel wrote:
> menuitem_get_properties_new_cb:
>   - I'd normally check that data != NULL before accessing its members

Fixed.  (r34)

> menuitem_call_cb:
>   - I'd, normally check that returned pointer from g_new0 != NULL

Do you mean "parse_layout_xml"?  I believe that is the only call to
g_new0 in client.c, fixed :)  (r35)

> dbusmenu_client_add_type_handler:
>   - Would a check for type!= NULL make sense here, as you use it to lookup in the hashtable?

Fixed.  (r36)

>   - Does newfunc need to also be checked? Or is is okay to add a NULL func (i.e. to unset a previously set function)?

No, I think it's okay to have a NULL function.  We check when it's
pulled out, so there's no risk.  I'm not sure why you'd WANT to do that,
but I don't see any reason to restrict it.

> new_item_seperator &  new_item_normal:
>   - Are arg checks required for newitem, parent and client?

They're basically internal functions... but since people will probably
steal that code as examples when they make their own external ones it
makes sense to have it there, so they include it.  (r37)

> child_realized:
>   - I'd have g_return_if_fail (DBUS_MENU_GTKMENU (userdata)) before casting it as its a signal callback

I used DBUSMENU_IS_GTKMENU, but yeah. (r38)

-- 
https://code.launchpad.net/~ted/dbusmenu/types/+merge/10772
Your team ayatana-commits is subscribed to branch lp:dbusmenu.