Hi Daniel, > Thinking even further, we could probably even rename the old > ARES_OPT_SERVERS to ARES_OPT_SERVERS_OLD and introduce the new > ARES_OPT_SERVERS with a new bit (and do similar with the 'servers' and > 'nservers' firleds) and then not break ABI (as existing apps will continue > to run), but recompiles will automatically use the new way...
The problem is not on the ARES_OPT_* side, effectively if it was only located there something could be done. The root of the problem is that the ares_options struct is in the public interface since the pre-fork old ares days, and as such the library user is allowed to setup and fill with data an ares_options variable and feed it to ares_init_options(). If the ares_options struct would have been private to the library and the library would have only exposed functions to manipulate it from the public API we would not be talking of this now ;-) But this is what we have, and this means that nearly any change to the ares_options struct breaks ABI. BTW the change to the ares_options struct committed 2008/11/01 already breaks ABI, and requires applications recompilation. So maybe this could equally be committed and do whatever other ABI breaking changes are pending, if anyone has any in mind, before release. My 2 cents -- -=[Yang]=-