| 02:31.07 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 02:31.07 | *** topic/#asterisk-dev is 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 |
| 03:32.08 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 03:43.27 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 05:09.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d002db74b01cdd27da0.ipv6.abo.wanadoo.fr) |
| 06:07.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:a5de:48e2:c9e1:b7c0) |
| 06:32.32 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:32.32 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:13.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:e04e:8ac7:f191:c3f7) |
| 07:26.38 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:27.10 | *** join/#asterisk-dev ahmed89_ (~ahmed89@134.0.214.254) |
| 09:33.56 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 09:53.59 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 11:32.43 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:08.25 | file | the topic changer is fixed |
| 12:09.06 | file | it was broken for everything - they apparently fixed the hook execution so that "change_url" now contains the actual URL, and not just the change number |
| 12:44.27 | *** join/#asterisk-dev CELYA_ (~Thunderbi@92.184.104.104) |
| 12:50.54 | seanbright | unbelievable |
| 12:58.42 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@92.184.104.104) |
| 13:10.09 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.34.12) |
| 13:33.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:43.15 | seanbright | do we have STIR/SHAKEN support yet? |
| 13:43.16 | seanbright | :P |
| 13:43.28 | file | have you written it |
| 13:43.30 | file | :P |
| 13:43.59 | seanbright | touche |
| 13:51.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@120.25.srvc.fr) |
| 14:15.57 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-jupmitqnqurfnpbc) |
| 14:15.57 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:34.59 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-vfbgydtqefcwigor) |
| 14:34.59 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:47.24 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qijzpsevivsetcbp) |
| 14:47.24 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:53.35 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:53.35 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:30.24 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 15:30.24 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 15:32.57 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 15:58.25 | file | gtjoseph: what was the performance impact of your bridge stasis cache change? |
| 15:59.10 | gtjoseph | no idea yet. i need to do call tests to determine |
| 15:59.46 | gtjoseph | the big factor though will be the elimination of the stasis caching stuff |
| 15:59.52 | gtjoseph | from stasis itself |
| 16:44.29 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.162) |
| 16:51.12 | file | rmudgett: do you have a canned blurb for memory leaks? |
| 16:51.33 | rmudgett | no |
| 16:51.46 | file | bah |
| 16:51.54 | rmudgett | Isn't there a canned response in JIRA? |
| 16:54.17 | file | not for that... |
| 16:54.20 | file | memory corruption yes |
| 16:54.23 | file | file descriptor leak yes |
| 16:54.34 | file | gtjoseph: I think knowing the repercussion of it would be a good thing btw |
| 16:55.03 | gtjoseph | agreed. working on it |
| 16:55.31 | file | gtjoseph: I'd also be interested in seeing what my filtering thing did with it too |
| 16:56.09 | gtjoseph | can do. |
| 17:15.28 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 17:44.31 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 17:44.31 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 18:16.47 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ilbvflkfftdbrkdf) |
| 18:49.42 | *** join/#asterisk-dev ahmed89_ (~ahmed89@85.154.25.67) |
| 18:57.46 | coreyfarrell | rmudgett: I've updated https://github.com/akheron/jansson/pull/438 based on our discussion yesterday. I'd appreciate any feedback you might have. |
| 19:03.46 | gtjoseph | coreyfarrell: i wonder if i should do a link first so that we don't get a false positive when cross-compiling and the actual compile or link fails. |
| 19:08.21 | coreyfarrell | my suggestion would be to not use AC_RUN_IFELSE at all. it's not needed for unbound version detection since your test program will fail to compile for unacceptable versions. |
| 19:08.37 | gtjoseph | yeah i was trying to make the new macro generic |
| 19:12.37 | coreyfarrell | I think AC_LINK_IFELSE would be the best/most generic choice.. it's pretty rare that a configure.ac test actually needs to run the test program. |
| 19:12.53 | gtjoseph | how about this... |
| 19:13.40 | gtjoseph | do the link, then if cross_compiling != "yes", try to run the program. if cross_compiling = "yes", skip the run. |
| 19:15.05 | seanbright | so |
| 19:15.11 | seanbright | ASTERISK-28069 |
| 19:16.19 | seanbright | two ways to handle that in my mind. copy the string byte for byte and then walk the string backwards lopping off invalid utf-8. |
| 19:16.29 | seanbright | or ast_string_copy_utf8() |
| 19:16.33 | seanbright | thoughts? |
| 19:17.09 | seanbright | or the 3rd option - don't do anything |
| 19:18.46 | coreyfarrell | gtjoseph: I guess that would work but I still don't see the point of running the program. |
| 19:19.00 | seanbright | having a way to lop off invalid bytes at the end would come in handy for other ways that strings are generated |
| 19:19.06 | gtjoseph | in case there's some library function that returns the version |
| 19:19.32 | gtjoseph | we have a few of those iirc |
| 19:22.49 | rmudgett | seanbright: Fix it so everyone uses English :D |
| 19:25.01 | seanbright | that may actually be the easiest of the options |
| 19:33.20 | coreyfarrell | maybe jansson needs a way to set the way invalid utf-8 sequences are handled - error, drop or replace (obviously that wouldn't help existing versions) |
| 19:50.18 | rmudgett | having it remove the invalid utf-8 chars would be nice too |
| 19:52.41 | coreyfarrell | that's what I meant by 'drop'. so "test\xff\xff!" would become "test!". |
| 20:04.23 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 20:04.23 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 20:12.26 | seanbright | could that be potentially dangerous? |
| 20:12.50 | seanbright | actually, i haven't been following what you two are talking about, so ignore me |
| 20:13.01 | seanbright | silently dropping chars might not be the best course of action |
| 20:13.13 | seanbright | or bytes, i should say |
| 20:18.13 | seanbright | where is this invalid UTF-8 coming from? |
| 20:20.40 | rmudgett | seanbright: We were talking about packing strings into json objects that were invalid utf-8. |
| 20:21.13 | seanbright | so the strings that you are packing are invalid UTF-8? |
| 20:21.19 | seanbright | i'm asking where those strings are coming from |
| 20:22.20 | rmudgett | coreyfarrell: I think you need to remember what was packed in pack_object() as well as pack_array() so you don't apply an invalid '*' to something like '{' or 'i'. |
| 20:22.49 | coreyfarrell | if dropping invalid UTF is undesirable we could replace invalid sequences with "\xef\xbf\xbd" (the utf replacement character U+FFFD). though if the invalid UTF is due to truncation that won't help. |
| 20:23.02 | rmudgett | seanbright: Where those invalid strings were coming from is not specified. Anywhere |
| 20:23.10 | seanbright | ok |
| 20:23.26 | seanbright | then i think the longer term goal would be - never let invalid utf-8 in or out |
| 20:23.37 | seanbright | protect against it at the edges |
| 20:23.38 | coreyfarrell | I think I've seen invalid UTF from callerid in bug reports |
| 20:23.54 | rmudgett | yes the have come from callerid |
| 20:24.08 | seanbright | what channel tech? |
| 20:24.09 | rmudgett | dialplan is another source |
| 20:24.27 | coreyfarrell | rmudgett: you mean like json_pack("[*]")? can you give me an example format string you are worried about? |
| 20:24.37 | rmudgett | seanbright: dahdi where the isdn switch passed in bad data |
| 20:24.46 | seanbright | gotcha |
| 20:25.17 | rmudgett | coreyfarrell: {s:i*} |
| 20:25.30 | seanbright | json schmason is what i always say |
| 20:26.07 | seanbright | back in my day... |
| 20:26.14 | seanbright | GET OFF MY LAWN |
| 20:27.12 | rmudgett | You had to make your own vehicle tires out of stone? (Flintstones) :D |
| 20:27.22 | seanbright | yabba dabba yes |
| 20:27.56 | rmudgett | groan |
| 20:28.43 | json_bourne | {message: "groan all you want", apathy: true} |
| 20:30.06 | json_bourne | that's invalid. shit. |
| 20:30.16 | json_bourne | {"message": "groan all you want", "apathy": true} |
| 20:30.19 | json_bourne | there we go |
| 20:30.41 | file | better! |
| 20:33.37 | coreyfarrell | rmudgett: I just added a test for "{s:i*}", it throws an error "Expected format 's', got '*'". because ':' and ',' are not significant to the format it saw '*' where it expected an 's' for the next object key. |
| 20:34.02 | coreyfarrell | I also tested "[i*]", the error for that is "Unexpected format character '*'". |
| 20:34.59 | coreyfarrell | I'll amend my commit with those tests. |
| 20:36.52 | file | I liked that nick. |
| 20:37.04 | seanbright | well you'll see it again |
| 20:37.10 | seanbright | i registered it |
| 20:37.12 | seanbright | :P |
| 20:37.33 | coreyfarrell | rmudgett: the PR is updated with the new tests. |
| 20:39.39 | rmudgett | coreyfarrell: {s:f*} where you pass NAN for the double |
| 20:42.44 | coreyfarrell | '*' is only supported after s, O and o. so "{s:f*}" produces the same error as "{s:i*}" |
| 20:43.21 | coreyfarrell | rmudgett: even if you pass a valid double to "{s:f*}" it's not a valid format string so it will error on that. |
| 20:48.37 | rmudgett | hmm It would appear to be erroring out for other reasons than what I was thinking |
| 20:52.20 | rmudgett | coreyfarrell: pack_array() isn't setting an error message when pack returns NULL and valueOptional != '*' |
| 20:52.37 | rmudgett | Its just setting s->has_error |
| 20:52.53 | coreyfarrell | yeah I'm looking into json_pack("[f]", NAN) right now |
| 20:57.33 | rmudgett | The error message in pack_object_inter() should be "NULL object" not "NULL object key". Looks like a cut/paste error |
| 20:59.35 | coreyfarrell | rmudgett: I think the problem is that pack() should set_error when json_integer or json_real returns NULL? also ack on the pack_object_iter. |
| 21:01.36 | coreyfarrell | setting s->has_error in pack_array / pack_object is meant as a last-ditch effort to deal with an uncaught error. really at that point s->has_error should already be true. |
| 21:09.21 | coreyfarrell | rmudgett: do you think json_error_numeric_overflow is appropriate for NAN and infinity passed to "f"? |
| 21:09.51 | rmudgett | don't know I rarely use float/double |
| 21:10.32 | seanbright | mantissa my exponent |
| 21:10.39 | seanbright | pardon my language |
| 21:11.59 | rmudgett | coreyfarrell: Seems to be the best pre-defined error for NAN |
| 21:12.58 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 21:15.04 | rmudgett | file: That user's list query about pjsip_tls_transport_start2 not defined: Is that because of stale pjproject on the system? |
| 21:16.02 | file | Can be |
| 21:16.41 | rmudgett | I've seen that recently on the users forums but cannot remember the solution |
| 21:39.45 | coreyfarrell | rmudgett: I just pushed an additional commit to my PR to deal with invalid numbers and allocation failures of numbers. |
| 21:40.30 | coreyfarrell | also wow this PR got much bigger than I expected. I appreciate your eyes on this you've caught a bunch of things that I didn't think of. |
| 21:40.48 | file | rmudgett: I do not recall either |
| 21:53.33 | rmudgett | coreyfarrell: Looks ok to me |
| 21:55.15 | coreyfarrell | great I'll let @akheron know that we think it's ready for merge. |
| 23:21.32 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jupmitqnqurfnpbc) |