On Thu, 20 Dec 2007, Yang Tse wrote:

> For systems capable of running configure its nearly finished. But in
> think that in types.h.dist we also have to address systems that aren't
> capable of running the configure script, and provided config files for
> those might also need adjustments (amiga, msdos vms?). Inclusion of
> types.h from curl.h

Right, but if we provide a decent framework to add this it should be easy for
people using these operating systems to fix this.

> The release/snapshot process should copy types.h.dist as types.h for all
> systems (I prefer leaving this last one for you, I'll do the other ones)

This is in fact already done. There's a generic script in the root Makefile.am
file that scans all subdirs for .dist files to rename, for release. That's how
we make the include/curl/curlver.h file as well etc.

Ah, another detail to fix is that include/curl/Makefile.am has a 'CLEANFILES =
*dist' line, which then rather should explicitly mention the ones to remove
since the types.h.dist shouldn't really be removed on 'make clean'

>> Is this method working fine if we try to install the headers when we build
>> outside the source dir on a *nix box? I guess I need to check it out...
>
> Don't know. I'll try this later today.

I've tried it now and it seems to work fine.

>>> Should we go this route ?
>>
>> Do we have any other reasonable approach to select from? To me
>> this seems like a doable way at least.
>
> Even if we do this. socklen_t in the interface will hunt us back again for
> some platform not capable of running the configure script. At least we
> reduce the possibility.

Yeah. :-/

The question is perhaps what the possible punishment will be on us if we try
to revert the socklen_t introduction. On what platforms will changing
socklen_t over to for example 'unsigned int' make a difference?

The Single UNIX specification[1] says socklen_t "is an unsigned opaque
integral type of length of at least 32 bits. To forestall portability
problems, it is recommended that applications should not use values larger
than 2^32 - 1."

We can't use size_t, since it seems ISO/IEC 9899:1990, Programming Languages -
C (ISO C)[2] says "size_t must represent the largest unsigned type supported
by an implementation", so on a 64 bit architecture, socklen_t and size_t are
likely to differ, or at least there will be such architectures.

I googled around for a while, but I couldn't find a single architecture that
has a socklen_t that isn't 32bit...

[1] = http://www.opengroup.org/onlinepubs/7990989775/xns/syssocket.h.html
[2] = http://www.usenix.org/publications/login/standards/10.data.html
    (although you can find that quote mentioned at several places online)

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