comparison libpurple/protocols/msn/slp.c @ 17135:acde78931954

slpcall now explicitlt references its xfer and unreferences it when it is destroyed. While it *looks* like this should *probably* have happened anyways due to the interactins between xfer_init, xfer_end, and xfer_cancel_remote, having the xfer's owner make this explicit makes the process less fragile and more obvious, and it may fix a crash as the slp is destroyed. Fixes #1070

17084:10c7c5d4ea25

			purple_xfer_set_init_fnc(xfer, msn_xfer_init);
			purple_xfer_set_request_denied_fnc(xfer, msn_xfer_cancel);
			purple_xfer_set_cancel_recv_fnc(xfer, msn_xfer_cancel);

			slpcall->xfer = xfer;
			xfer->data = slpcall;

			purple_xfer_request(xfer);
		}
	}

17135:acde78931954

			purple_xfer_set_init_fnc(xfer, msn_xfer_init);
			purple_xfer_set_request_denied_fnc(xfer, msn_xfer_cancel);
			purple_xfer_set_cancel_recv_fnc(xfer, msn_xfer_cancel);

			slpcall->xfer = xfer;
			purple_xfer_ref(slpcall->xfer);

			xfer->data = slpcall;

			purple_xfer_request(xfer);
		}
	}