[sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Daniel-Constantin Mierla writes:

> As I wrote on the mailing list, flags should not be migrated to the
> transaction after t_newtran() unless one uses t_flush_flags() -- that
> was the desired functionality, otherwise t_flush_flags() has no
> purpose.

I have used flags for many years and for me it has been desirable that
they are available after t_newtrans() in failure and onreply routes
without a need to call t_flush_flags().  If someone wants to change that
behavior and make t_flush_flags() purposeful, then a tm variable can be
introduced to achieve that new behavior.

> You opened another item on this tracker related to this unexpected
> behaviour (#1490), and I think it is better to sort this out there,
> because that is the unexpected behaviour. xflags behave as
> expected. Whatever will be the conclusion of #1490 will be applied to
> both flags and xflags, but makes no sense to track an issue with two
> separate items.

I opened this issue, because I needed more that 32 flags, i.e., flags
that work the same way as before, but more of them.  It is OK to replace
flags with xflags if my current configuration file keeps on working when
I textually change current flag function calls with xflag function
calls, but it is not OK if I need to start adding t_flush_xflags() calls
to it.

Issue "Is t_flush_flags() really needed? #1490" asks about the purpose
of t_flush_flags() function.  I have not been able to figure out one,
but perhaps there is some.  If there is no purpose, then the function
should be removed.

-- Juha


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1288#issuecomment-378838094
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180405/c07d5a10/attachment.html>