c-ares API vs c-ares source code provided functions (Win32 recommended reading)

Hi Daniel and all,

Some systems lack functions which c-ares can provide very easily
making them part of the c-ares API or providing them simply as source
code. Affected function list:

ares_inet_net_pton, ares_inet_ntop, ares_inet_pton, ares_strcasecmp,
ares_strncasecmp and ares_getopt.

Now that internal c-ares private symbols are hidden by default when
building a shared library, dll on Win32, all this becomes more
relevant.

I clearly remember that this issue was discussed on the list for
ares_getopt and that back then the outcome was that ares_getopt did
not belong to the c-ares API, and that it should be simply considered
a source code provided function. This is fine since ares_getopt.c and
ares_getopt.h are self-contained and don't require the assistance of
ares_setup.h, so actually source-code including it in any application
does not additionally force to also include private parts of c-ares
such as ares_setup.h nor any of the configuration files used to build
the library.

Our mingw makefile (Makefile.m32) has only allowed the creation of a
static c-ares library.

Our Makefile.vc6 already allowed creating both shared and dynamic
c-ares libraries. With the 'twist' that the c-ares shared library
_did_ export ares_inet_net_pton, ares_inet_ntop, ares_inet_pton,
ares_strcasecmp and ares_strncasecmp using an export file mechanism.

Now that the c-ares external API has __declspec function decoration
for Win32 and systems supporting it, the export file mechanism becomes
mostly an inconvenience, and for consistency sake, _IF_ mentioned
functions are going to be exported by c-ares they also should also be
using the __declspec decoration.

Now that by default internal c-ares functions are not exported when
building a shared library for non-Win32-like systems something similar
as the above could be done to provide mentioned functions in the
external API.

If providing these functions is something that is going to be done
based on system's unavailability, or perhaps build target, we could
maybe move the prototypes of these functions to ares.h and declare
them conditionally there.

On the other hand if all of them are removed from c-ares external API
and simply provided as source code that can be used by applications,
it implies that ares_setup.h and ares internal configuration files
must also be included by the application using them.

No matter which way we go Win32 makefiles must be adjusted. Obviously,
depending on which route we officially take the changes are also
different.

So...

Conditional c-ares API or c-ares source code provided functions?

-- 
-=[Yang]=-