<p><a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16205">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16205/26/src/gsupclient/gsup_req.c">File src/gsupclient/gsup_req.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16205/26/src/gsupclient/gsup_req.c@142">Patch Set #26, Line 142:</a> <code style="font-family:monospace,monospace">osmo_gsup_req_free</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Actually I want to avoid bugs by including the free everywhere implicitly. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">Taking another look...</p><p style="white-space: pre-wrap; word-wrap: break-word;">(I notice that osmo_gsup_make_response() also changes the session_state in the response message depending on the final_response flag. So I need a final_response flag anyway, even if the free were a separate call.)</p><p style="white-space: pre-wrap; word-wrap: break-word;">Having the free() implicitly as soon as there is a final response enforces a request-response relation in GSUP.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Some background...<br>{<br>The typical case is: rx GSUP, tx response.<br>With the new osmo_gsup_req we can easily expand to: rx GSUP, wait async, tx response.<br>Only few GSUP constructs go beyond a 1:1 request-response match.</p><p style="white-space: pre-wrap; word-wrap: break-word;">But some have a session or more negotiation may happen before the initial request is completed, so<br>the final_response flag adds: rx GSUP, wait async, [tx other, wait async, rx other...,] tx final response.</p><p style="white-space: pre-wrap; word-wrap: break-word;">By definition, all of these either end in a final response or an error.<br>So I want to tie the lifetime of the osmo_gsup_req to the req -> resp/err cycle,<br>to avoid memory leaks and enforce the GSUP request-response model.<br>}</p><p style="white-space: pre-wrap; word-wrap: break-word;">We could argue that we may not want to enforce a req -> resp/err like this?</p><p style="white-space: pre-wrap; word-wrap: break-word;">Personally I don't like very much that the final_response is just a little 'true'/'false' that is easy to miss when reading code; but I also don't want to multiply nr of function signatures by two by adding nonfinal functions (osmo_gsup_req_respond{_nonfinal}, osmo_gsup_req_respond_msgt{_nonfinal}). Making the true/false flag more obvious could be done by an enum value (osmo_gsup_req_respond(GSUP_RESP_FINAL, ...)). An enum value also opens the door to different ways to do a GSUP response in the future, if ever needed (like a "final" response but doesn't free??).</p><p style="white-space: pre-wrap; word-wrap: break-word;">mem leaks: using msgb(), we often have/had hidden memleaks.<br>With an implicit free we may be able to mostly avoid the entire class of gsup_req memleaks.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I think I would implement the GSUP_RESP_[NON]FINAL enum value now and keep the free() implicit.<br>Seems to be the most future proof yet most bug avoiding option.</p><p style="white-space: pre-wrap; word-wrap: break-word;">But since changing this ripples across multiple files in multiple patches, I'd like more opinions before I change anything. If no opinions, I guess it should just remain unchanged...?</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16205">change 16205</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16205"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-hlr </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9 </div>
<div style="display:none"> Gerrit-Change-Number: 16205 </div>
<div style="display:none"> Gerrit-PatchSet: 29 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: osmith <osmith@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 28 Apr 2020 13:50:11 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Comment-In-Reply-To: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>