Attention is currently required from: pespin, fixeria.
2 comments:
File include/osmocom/bsc/bsc_msc_data.h:
Patch Set #1, Line 140: struct gsm_audio_support audio_support[16];
you say there's 14 but you put 16 here?
No, i write "Let's just make it:" ... 16; which is larger than 14, and has ample room for users with weird codec-lists. I never like to put the actual nr in the comment, because code changes, and typically the comments fail to change along with the code. (same as writing "for these two reasons:" and then five reasons follow -- just write "for these reasons:" and it won't go stale)
Actually there can't be more than 13, because fr1-fr7 plus hr1-hr7 less hr2 is 13, and soon duplicates will be disallowed. But 16 is a power of two, and 13 has ... idk ... religious meaning or something.
It doesn't really matter... want me to change it??
File src/osmo-bsc/bsc_vty.c:
It's actually a size_t afaiu, so %zu.
no, the compiler complained that it is 'long unsigned int' -- but my guess is that it's architecture dependent? So whichever format I choose, it is bound to be wrong somewhere ... Now that I think of it, that might actually not be the case at all. our ARRAY_SIZE is defined as 'sizeof(..) / sizeof()', so actually I also expect it to be size_t... now I'm confused, why did my compiler say 'long unsigned int'
Casting to (int) is a simple way to be sure it is correct, because i absolutely know that the array size is in int range, and we can skip the discussion. what do you think?
To view, visit change 31609. To unsubscribe, or for help writing mail filters, visit settings.