On Mon, May 11, 2015 at 9:16 AM, Alexander Traud <pabstr...@compuserve.com> wrote: >>> B) Change my patch not to use a char* but char[128]. >> Your easiest option with less chance of regression elsewhere would be this. > > Yes. Anyway: Is the Asterisk team interested in a patch at least for the 5 > affected files? These are 54 changes. I am not sure if the path via an issue > (Jira) and a commit (Gerrit) is welcome for something like this. > > Furthermore, again there are several options: > I) in those 5 files, report only those 54 changes which I need; or > II) in those 5 files, correct *all* struct inits > The latter is interesting, because there are memsets(.) which get > unnecessary then. This created an additional option/question: > III) shall I remove all - then duplicate - struct inits as well? > > Or shall I stop wasting anyone's time and go for option B, a char[128]?
I wouldn't say you're wasting anyone's time. It's a good question. What you're proposing is a change to the semantics of ast_sockaddr in order to accommodate a change in a patch you're making. A few things to keep in mind: 1) Your module/patch, as well as the rest of the Asterisk modules, may not be the only consumers of ast_sockaddr. It is a fundamental data structure in Asterisk; other third party modules may use it. Since your change modifies the semantics of the struct, you will also break them. 2) If the rest of your patch is never pushed back up to the main project, then the change you've made has little positive affect, while breaking most other external modules that use it. That's not good for the project. On the other hand, if you propose your feature for inclusion as well, there's more of a benefit to the change. That aside, if you can make a change with a little bit more work that maintains the existing usage semantics, you get the best of both worlds: your new feature gets what it needs, and the mainline Asterisk project - as well as other third party modules - aren't broken. So yes, I'd just use a char array with a fixed length. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev