| 05:58.16 | snuff-work | mm.. anyone know what 'pygments' style might be close 'enough' to asterisk extensions.conf style? |
| 06:21.22 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.52) |
| 07:14.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 08:10.54 | *** join/#asterisk-dev electronic_eel (~quassel@HSI-KBW-46-223-65-185.hsi.kabel-badenwuerttemberg.de) |
| 08:18.40 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:29.51 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:edef:f202:ebf7:e402) |
| 08:40.24 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:6169:85ce:6cc0:f2b5) |
| 09:52.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 12:56.56 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 13:50.21 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 15:02.30 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-uftzzraxiunrslvv) |
| 15:02.30 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 17:02.37 | *** join/#asterisk-dev dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 17:50.10 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.100) |
| 18:42.29 | seanbright | probably a question for rmudgett and/or gtjoseph |
| 18:42.50 | seanbright | if i have a struct. say something like: |
| 18:43.19 | seanbright | struct foobar { uint16_t a; uint32_t b; char c[18]; uint32_t d; } __attribute__((packed)) |
| 18:44.09 | seanbright | can i fread/fwrite the whole thing in one call without worrying about cross-platform concerns? |
| 18:44.29 | seanbright | i know that i can't take the address of any of the fields safely, and that endianess is a separate issue |
| 18:44.47 | seanbright | but does "packed" mean "packed" regardless of the architecture? |
| 18:50.18 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.100) |
| 19:05.30 | rmudgett | seanbright: No packed just means the padding in the struct is not present. It does nothing about endianness of multi-byte ints. |
| 19:06.10 | rmudgett | In your example there would be padding between a and b because a is two bytes and b is four bytes. |
| 19:08.02 | rmudgett | 16 bit ints are aligned on two byte boundaries, 32 bit ints are aligned on four byte boundaries. Thus to maintain that alignment there would need to be padding bytes after the a member to get the alignment needed by the b member. |
| 19:14.06 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.100) |
| 19:15.47 | seanbright | rmudgett: there would be padding even with the packed attr? |
| 19:23.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 19:34.34 | rmudgett | no that attr tells the compiler to not put the padding into the struct |
| 19:36.24 | seanbright | rmudgett: ok. so sizeof(struct foobar) will be the same on x86, x86-64, arm, etc? |
| 19:36.29 | seanbright | (assuming compiled with gcc) |
| 19:37.35 | rmudgett | not necessarily. the size of plain ints is dependent upon compiler and cpu architecture. |
| 19:37.56 | seanbright | ok |
| 19:39.10 | seanbright | so then the only reliable cross-platform way to read/write that struct is fread/fwrite the members individually. is that correct? |
| 19:40.59 | rmudgett | The only universal way is to do it byte by byte. |
| 19:41.12 | seanbright | ok, then maybe i have phrased my question poorly |
| 19:41.18 | seanbright | IN PRACTICE... |
| 19:41.24 | seanbright | then read the whole thing again |
| 19:41.27 | seanbright | heh |
| 19:41.37 | seanbright | on the platforms asterisk supports... <insert above question> |
| 19:42.04 | seanbright | i'm not getting the answer that i want, which is why i keep asking i think. |
| 19:43.32 | rmudgett | The architectures you've mentioned (x86, x86-64, arm) should encode the same as they are all little endian machines |
| 19:44.14 | rmudgett | Its just that you really don't want to depend upon that kind of thing |
| 19:45.14 | seanbright | https://github.com/asterisk/asterisk/blob/master/formats/format_wav.c#L81-L138 |
| 19:45.30 | seanbright | i refuse to believe that this demonstrates the best way to read a fixed binary header |
| 19:45.36 | seanbright | change my mind |
| 19:45.36 | seanbright | heh |
| 19:53.09 | kharwell | I'm not going to pretend I know everything on the subject, but based on past reading, and such I'd go the byte by byte route. |
| 19:54.04 | kharwell | it's your safest bet. Universal. Plus should be easier to debug if something goes wrong or you really want to know if byte 4 through 8 is what it's suppose to be |
| 19:57.08 | seanbright | alright |
| 19:57.20 | seanbright | thanks for the input |
| 20:20.51 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-758-77.w86-236.abo.wanadoo.fr) |