On Mon, 10 Dec 2007, Yang Tse wrote:

>> It hurts inside me, but I really can't see a way to avoid it. Have you
>> given any further thoughts on how the configure magic and header file in
>> the include would look and work like?
>
> The magic for this would need something quite similar to the attached patch.
> It is incomplete, and besides curl.h needing to #include types.h most
> probably other parts of the build process would need adjustments. But I
> think it is enough to get the idea of one way it could probably be done.
> Sure it can be further improved.

Yeps, it looks functional. 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 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.

> I'm not sure if we actually want the 'magic way' or if it would just be
> better to let the user manually include the definition in curl.h when he
> actually needs it.

I don't like that, as on platforms where there is no socklen_t it is far from
obvious to people that this is what they would need to do, and even if they
figure that out we'd need to include a largish instruction as to what a
suitable replacement is etc.

> Or even further get rid of 'socklen_t' in curl.h and just use 'size_t' ?

Yeah, I wish we did that before we introduced that struct, but now we risk
breaking both ABI and API if we change this (if a platform has size_t and
socklen_t that differ). I think I favour the configure-based approach.

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