> The parameters of the only function (that I could find) that takes
> an ares_options are always copied and never modified. i.e. All
> receivers of an ares_options structure require only immutable access
> to the pointed-to resources.
We're not talking about 'receivers' here. You're talking about making
an API break for people who are using this structure. I didn't define
the structure, but changing the members arbitrarily to const doesn't
make any sense for maintaining compatibility regardless of how much
'easier' it is for you. Also, note that there are more members in
there than just the 'lookups'. If you're changing the servers, and
domains as well, that means that people that utilize those are
going to have to allocate those external to the structure and maintain
those separately. Most likely that means they'll have a shadow struct
of some sort with this data, that doesn't make sense.
I don't see a justification here for you to make an API breakage just
so you can do options.lookups = "bf" instead of doing a strdup()
and free()'ing it later. If I were taking away already existent
consts, then you'd have an argument.
>
> I don't agree that the fact that you've chosen to overload the
> ares_options structure for storage in your patch means that other
> uses and other needs are invalid. The existing ares_options structure
> does not include any ownership semantics, and giving it ownership in
> some circumstances (i.e. when set ares_save_options()) but not others
> (existing usage in channel initialization) seems problematic.
What are you talking about here? I've not overloaded anything. And
I have no clue what you're talking about with the whole 'ownership'
thing. I've added a routine to save the channel settings to the
already-existent options struct ... I've also added sortlist support
to the options struct. Seems pretty legitimate, and I'm not the
one _changing_ the constification of the struct, you are.
-Brad
Received on 2007-05-17