Closed ghost closed 5 years ago
Oh welp this is my fault in #164 I guess
Instead of adding in specific null pointer handling, I reworked it to get the ID from the request and to use get_user to get the user from that, instead. This is probably a messy fix and a better fix would be to break up discord_handle_relationship into more than one function and handle each seperately.
Why though? Handling nulls in actually nevermind, i guess the old code silently failed to process this event, the name is needed for the discord_canonize_name
seems easier and cleaner than thiimcb_buddy_status
call.
Handling nulls in discord_canonize_name
would still be a good idea.
I did think about that but I figure if a null pointer is being passed to discord_canonize_name, it'd be hiding actual errors unless a real warning was given in debug output...?
Yeah just g_return_val_if_fail(string, NULL);
, that takes care of the warning.
I think that's all of them?
I think that's all of them?
Yep, looks good now. Thank you again, merged.
Before these fixes, RELATIONSHIP_REMOVE would cause a segfault. My understanding of this, is that RELATIONSHIP_REMOVE's json looks like:
{"t":"RELATIONSHIP_REMOVE","s":97,"op":0,"d":{"type":1,"id":"<removed>"}}
and this is the primary cause of this problem.In the original code,
json_value *uinfo = json_o_get(rinfo, "user");
would lead to a null pointer being fed into discord_canonize_name aschar *name = discord_canonize_name(json_o_str(uinfo, "username"));
has no handling for being fed a null pointer. This then causes a segmentation fault, as follows:Instead of adding in specific null pointer handling, I reworked it to get the ID from the request and to use get_user to get the user from that, instead. This is probably a messy fix and a better fix would be to break up discord_handle_relationship into more than one function and handle each seperately.