NormB left a comment (kamailio/kamailio#4644)
> I'm not familiar with that part of tm. I'm just worried about possible
> side-effects of changing long-standing code for multiple cases while fixing
> only a single failure case. Given the path 3 conditions, I do think the
> original `==` in path 1 was a deliberate choice and it should be checked very
> carefully if all path 3 conditions can be merged in path 1. That's why I
> suggested changing it only for the case at hand (`REQ_FWDED`) and evaluating
> against
> [2812bd9](https://github.com/kamailio/kamailio/commit/2812bd9c426d7a186bdc9b1d5fc4766315a64290).
> Unfortunately,
> [2812bd9](https://github.com/kamailio/kamailio/commit/2812bd9c426d7a186bdc9b1d5fc4766315a64290)
> does not provide a explanation on why it was added to path 3 instead of 1.
I've got the entire history of t_unref() path 3 from day 1 in 2003. After
reading the entire document, it does make sense and details each commit, when
it was made along with the author and commit message. If you like, I can append
the markdown of the entire document here.
This is the Summary:
This document traces the git history of the three cleanup paths in t_unref() to
answer the question: was the == in path 1 a deliberate choice, and is it safe
to replace it with &?
The answer: path 1's == was correct when written because REQ_ERR_DELAYED
couldn't coexist with other flags at that time. Path 3 was added two days later
as a diagnostic BUG catcher, not as an alternative cleanup path. Two subsequent
commits narrowed path 3's trigger to suppress false positive BUG messages. The
== in path 1 was never revisited during those changes — understandably, since
the focus each time was on the noisy BUG log rather than the broader cleanup
logic.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4644#issuecomment-4069598491
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4644/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
