| 01:27.03 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 05:12.10 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-114-57-249.dhcp.davl.vt.charter.com) |
| 05:12.10 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 06:15.14 | *** join/#asterisk-dev dakudos (~dakudos@c-73-217-33-206.hsd1.co.comcast.net) |
| 07:17.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 08:12.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 08:29.38 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 08:37.48 | *** join/#asterisk-dev s3c70r (~user@gateway/tor-sasl/s3c70r) |
| 08:55.21 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 09:22.53 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:31.33 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:31.33 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:28.35 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 12:58.24 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 13:02.47 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 14:29.21 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-rszeidenvvqggkji) |
| 14:29.21 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:43.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.169) |
| 14:49.20 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 14:57.55 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.169) |
| 15:00.05 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 15:21.16 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 15:33.26 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-dknjiwajksyondth) |
| 15:33.26 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:52.19 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 15:59.17 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 16:06.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 16:11.17 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 16:35.03 | seanbright | so if i wanted to have a stack allocated structure, the definition of said structure needs to be "public" |
| 16:35.10 | seanbright | and i assume there is no way around that |
| 16:35.32 | gtjoseph | context? |
| 16:35.57 | seanbright | well, i am working on something and i have a struct - let's call it foo |
| 16:36.19 | seanbright | i want to be able to declare a local variable: struct foo blah; |
| 16:36.47 | seanbright | but in order to do that, the struct definition needs to be known by that compilation unit |
| 16:36.55 | seanbright | to size things properly |
| 16:37.05 | file | the only other way is an alloca, and having a function which returns the size, allocs, and casts |
| 16:37.22 | seanbright | ah, yes. |
| 16:37.25 | seanbright | interesting. |
| 16:37.56 | seanbright | but i wouldn't be able to return that from a function to the caller |
| 16:38.04 | seanbright | which is meh |
| 16:38.09 | file | right |
| 16:38.21 | seanbright | what if i did something like: |
| 16:38.37 | seanbright | in the header file: struct foo { char data[128]; }; |
| 16:38.56 | seanbright | where 128 is the packed size of the opaqified struct |
| 16:39.06 | file | should work |
| 16:39.37 | seanbright | i don't know that i really care that much |
| 16:39.56 | gtjoseph | you're then going to pass that to lower level functions? |
| 16:40.21 | seanbright | i just want a stack allocated struct without making the definition public |
| 16:40.44 | gtjoseph | can't you just define the structure in the function that allocates it? |
| 16:40.56 | seanbright | well this is going to be an API |
| 16:41.35 | gtjoseph | so what's going to happen to the allocated structure? |
| 16:42.24 | seanbright | ok, so there are two use cases i am thinking about... ignore everything i have said so far |
| 16:42.35 | seanbright | char data[128]; |
| 16:42.45 | seanbright | struct foo blah = wrap_it(data, sizeof(data); |
| 16:43.08 | seanbright | operate_on_foo(&blah); |
| 16:43.12 | seanbright | ... etc ... |
| 16:43.17 | seanbright | then: |
| 16:43.40 | seanbright | struct foo *blah = make_one_dynamic(); |
| 16:43.47 | seanbright | operate_on_foo(blah); |
| 16:43.50 | seanbright | ... etc ... |
| 16:44.22 | seanbright | in the former case, there are no calls to malloc/calloc, so nothing needs to be cleaned up |
| 16:44.35 | seanbright | the latter requires a call to free |
| 16:44.37 | gtjoseph | wrap_it and make_one_dynamic can't return something they allocated on their stacks because the stack frame goes away when the function ends. |
| 16:44.51 | gtjoseph | unless i'm misunderstanding something |
| 16:44.55 | seanbright | wrap_it can return a struct |
| 16:45.04 | seanbright | by value |
| 16:45.11 | seanbright | unless *I* am misunderstanding something |
| 16:45.15 | gtjoseph | hmmmmmm. |
| 16:45.30 | seanbright | i mean... i think it can |
| 16:45.31 | seanbright | heh |
| 16:46.09 | gtjoseph | I've never actually tried it. |
| 16:46.42 | gtjoseph | i guess the compiler would have to allocate addition space in the _caller's_ stack frame so the called function can return it. |
| 16:47.16 | seanbright | https://paste.ubuntu.com/p/Yj4YMJKgxK/ |
| 16:47.29 | seanbright | works... but i guess it could be UB |
| 16:47.48 | seanbright | the goal is to avoid memory allocation if possible |
| 16:48.04 | gtjoseph | yeah makes sense. i've just never tried it. |
| 16:48.29 | gtjoseph | does google say you can do it? :) |
| 16:48.59 | seanbright | from stackoverflow: "You can return a structure from a function (or use the = operator) without any problems. It's a well-defined part of the language." |
| 16:49.06 | kharwell | I believe too when you return a struct like that it ends up copying things. So careful too on what's copied, sizes, and if a deep copy of pointers need to be done, etc... |
| 16:49.09 | seanbright | take with grain of salt |
| 16:50.04 | seanbright | kharwell: good point. the only pointer will be a uint8_t * |
| 16:50.16 | seanbright | which might point to a stack allocated buff |
| 16:50.19 | seanbright | er* |
| 16:50.33 | seanbright | i think ast_frame works kinda like this |
| 16:50.58 | seanbright | there would be a flag in the struct which indicated if the * was "owned" by the struct or not |
| 16:51.02 | seanbright | anyway |
| 16:51.25 | seanbright | i'll just have the struct definition be public and move on with my life |
| 16:51.39 | seanbright | if you mess with the fields without going through the API, it's your own fault |
| 16:52.16 | file | that be bad, yo |
| 16:52.21 | file | naughty people doing such a thing |
| 16:53.56 | gtjoseph | does the caller have to know the length? |
| 16:54.16 | seanbright | define 'caller' |
| 16:54.39 | gtjoseph | the function that gets the "structure" back from the allocator |
| 16:55.22 | gtjoseph | i guess if they are going to pass it to something else, the compiler would have to know. |
| 16:55.28 | gtjoseph | nevermind |
| 16:55.31 | seanbright | well it would be a local in the caller |
| 16:55.37 | seanbright | which needs stack space |
| 16:55.41 | gtjoseph | yeah |
| 16:55.58 | gtjoseph | i just rememberd that :0 |
| 16:59.19 | kharwell | seanbright: you other option is to use c++ :-P |
| 17:01.29 | rmudgett | You can only deal with opaque structs if you pass pointers to the struct around. Anything else requires the compiler to know about the layout of the struct. Then it wouldn't be an opaque struct anymore. :D |
| 17:02.26 | gtjoseph | he could still do the char[128] thing though (or unsigned char[128]) |
| 17:06.08 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 17:10.28 | seanbright | that would be ugly and error prone |
| 17:10.49 | gtjoseph | well, it was _your_ idea :) |
| 17:11.00 | seanbright | that is true. i have ugly and error prone ideas. |
| 17:11.03 | seanbright | happy!? |
| 17:11.10 | gtjoseph | yep |
| 18:59.56 | kharwell | to whomever looks at the srv failover review (https://gerrit.asterisk.org/c/asterisk/+/13228) please pay especially close attention to the tdata ref counting to make sure it's correct |
| 19:01.21 | file | suggests adding review comment with that |
| 19:22.11 | rmudgett | Do you want fries with that? |
| 19:22.59 | kharwell | ya fries sound good thanks |
| 21:40.35 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 22:08.07 | *** join/#asterisk-dev seanbright (~sean@asterisk/community-developer/seanbright) |
| 22:08.07 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |