Luigi Rizzo b7945cd78e
Cleanup of flags used in struct sip_request, moving them to ...
individual variables. Apart from SIP_PKT_IGNORE which was used
a zillion times, the other two are used seldom.
On passing:
- move the arrays to the end of struct sip_request, so a (small)
buffer overflow is less likely to overwrite the other fields;
- note that the 'ignore' argument to handle_invite_replaces() is not
used and should be removed (will be done in a separate commit).
Nothing to backport in this change.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-22 18:41:57 +00:00
2007-02-03 10:12:20 +00:00
2007-07-19 04:45:20 +00:00
2007-07-06 15:47:16 +00:00
2007-07-18 19:47:20 +00:00
2007-06-14 19:39:12 +00:00
2007-06-14 19:39:12 +00:00
2007-06-27 22:58:53 +00:00
2007-07-18 15:26:52 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-06-27 23:14:39 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-07-18 19:47:20 +00:00
2007-07-05 07:45:21 +00:00
2007-06-14 19:39:12 +00:00
2007-06-06 21:20:11 +00:00
2007-07-18 19:47:20 +00:00
2007-07-22 18:41:57 +00:00
2007-07-20 20:33:34 +00:00
2007-07-05 15:29:24 +00:00
2007-07-18 19:47:20 +00:00
2007-07-18 19:47:20 +00:00
2007-07-17 20:49:09 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-04-28 21:26:00 +00:00
2007-07-06 15:47:16 +00:00
2007-07-05 07:45:21 +00:00
2007-07-06 15:47:16 +00:00
b7945cd78e