On Mon, 17 Dec 2007, Yang Tse wrote:

>> 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 ?

It would simly mean that include/curl/curl.h would have a #include "types.h"
before it would use socklen_t. Since the types.h header would only define the
type if it truly must define it, as all other systems would already provide it
in their system headers.

>> 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.

True. Perhaps we should at least define HAVE_SOCKLEN_T when we define it
ourselves.

>> 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.

[...]

> 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.

Yeah. I did proceed and experimented further with this approach but I found
several obstacles, so I think I'll dump it (again).

Back to square one: using socklen_t in a public API was a stupid idea.

Is there any reason why types.h.in (with the default types.h not defining any
socklen_t type at all) won't work?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html