| 04:57.19 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 04:57.19 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 06:14.37 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.105) |
| 07:10.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:14.10 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.105) |
| 07:18.50 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 08:28.26 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 09:11.29 | wdoekes | seanbright: re: function pointer: sure, although passing function pointers is not the common idiom in chan_sip. I think an enum is probably more chan_sippy. (in fact, there already is an enum xmittype. I'll use that) |
| 10:00.26 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:00.59 | seanbright | wdoekes: good deal |
| 14:19.19 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-211.bstnma.fios.verizon.net) |
| 14:28.13 | *** join/#asterisk-dev _Vile (~abcdefg12@freeswitch/developer/vile) |
| 14:48.19 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.105) |
| 14:50.08 | gtjoseph | coreyfarrell: tested a module compiled with asterisk/32bit-ast_options running under asterisk with 64bit ast_options. No issues. The reverse does have a small issue... |
| 14:52.24 | gtjoseph | A module compiled against asterisk/64bit-ast_options but running against a 32-bit ast_options can read and write anything in the lower 32 bits bit if it tries to set or get something in the upper 32 bits, it'll overwrite what's after the options. (pjproject max log level) |
| 14:53.03 | gtjoseph | I don't consider that to be ABI breaking. |
| 14:54.01 | gtjoseph | independent module developers have to handle that already. |
| 15:00.40 | coreyfarrell | yeah that seems fine. isn't it generally frowned upon for modules (or anything really) to write ast_options after fullybooted? |
| 15:01.58 | coreyfarrell | I'd expect the flags to all be set early in startup by CLI options / asterisk.conf load, then be readonly since it doesn't have any locking and doesn't currently use atomics |
| 15:02.15 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-nyvbfxdmopdduxvj) |
| 15:02.15 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:07.25 | gtjoseph | yep, that's correct. |
| 15:08.03 | gtjoseph | and you can't reload asterisk.conf |
| 16:23.35 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:c5f4:9431:468c:af8b) |
| 16:25.03 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:c5f4:9431:468c:af8b) |
| 18:29.07 | *** join/#asterisk-dev sduthil (~sduthil@ipagstaticip-cf899324-841a-2614-948a-7dbf21746b29.sdsl.bell.ca) |
| 23:38.06 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |