> We can of course also make it include/curl/types.h.in and just let
> configure generate the types.h file from that, like config.h works...

I like this approach but I'm unable to see how conditional definition
would be done. I'm not saying it can't be done. Let's say that
configure has detected that socklen_t needs to be defined, that means
that curl.h will also need the definition so it should pull it from
types.h generated from include/curl/types.h.in How would this last
file look like relative to this definition ?

> I don't want it to rely on any HAVE_* symbols though, as they're
> not within our name scope and it will be used by configure-based
> applications (that include this header) and may actually not have
> the exact same meaning as we put into it.

A possible not so bad point of using some HAVE_* symbols is that they
can also be used as redefinition protection guards when several libs
try to define i.e. socklen_t in their public interfaces on platforms
that lack the definition. So exposing HAVE_* symbols for those that we
actually define in the public interface could even be a good thing.

> Actually, I'm now leaning towards bringing my old work on a configure-based
> config.h in the public headers back from:
>
> http://curl.haxx.se/mail/lib-2006-12/att-0084/curl-config-header.patch

In many library source files we include both curl.h and config.h, I
think that this would mean that things could get somewhat messy.

A platform that does not have a 'native' socklen_t definition now gets
one in config.h via...

#define socklen_t sometype

curl/config.h would have...

#define CURLCONF_socklen_t sometype

curl/types.h would need...

#ifdef CURLCONF_socklen_t
#define socklen_t CURLCONF_socklen_t
#endif

The above would satisfy the external interface need for a socklen_t definition.

But what happens when libcurl is built and both curl.h and config.h
are included ?

Eeek. Now config.h also needs to define CURLCONF_socklen_t or at least
HAVE_SOCKLEN_T. And I think that checking of symbols should be done at
both places to prevent redefinition when building libcurl.

As you said this is a tricky problem. And I think that any move done
should lead to less problems. Rather conservative for this, I hope
that this doesn't sound too negative. And I wish someone else would
join and comment anything.

After all the problem is that it seems that we want to provide a
socklen_t definition in the public interface for systems that lack the
definition, but taking in account that the library also pulls in the
external interface.

I hope this makes some sense.

Maybe I should try to complete the include/curl/Makefile.am solution
to find out other drawbacks it could have. Or even better how to use a
conditional definition in include/curl/types.h.in.

Somewhat puzzled,

-- 
-=[Yang]=-