2008/7/21, Jamie Lokier wrote:

> > Yes. But we certainly have to define an in/out variable to pass and
> > hold a value referenced by the void pointer. I have opted for an
> > unsigned int, http://cool.haxx.se/cvs.cgi/curl/ares/setup_once.h.diff?r1=1.29&r2=1.30
>
> That's an interesting choice, because it's the one type which no unix
> has ever used AFAIK :-)

:-) :-)

Well, its expected to hold the 'size' of something so it should not
need to be capable of holding a negative value.

> I'd go for `socklen_t' if it exists, because it might be a wider type,
> and if `socklen_t' does not exist I'd go for `int' or `unsigned int',
> doesn't matter (`int' being historically standard though.)

Of all the systems on the autobuilds the only one which was using a
void pointer prototype for the sixth argument of recvfrom() was the
Solaris one.

Googling around I have not found a single system which documents a
recvfrom prototype with a void pointer for the sixth argument.

It would be interesting if we would know of another system which does
it this way.

If a system makes the choice of providing a prototype for recvfrom
with a void pointer prototype for the sixth argument, it should also
document the expected size of the variable which is being to be
referenced with the void pointer, specially when that variable is used
by recvfrom() to receive and also return information.

Let's not loose to much focus and lets remember that the value held by
the variable is going to be the size of the sockaddr structure pointed
to by the fifth argument. So an int is more than enough to hold
potential sizes.

Arggh, I've just remembered the horrible things needed at the end of
lib/setup.h to cope with a system that has the socklen_t definition
and seems to have a real problem when using 64-bit ABI with default
interfaces which don't expect a 64-bit socklen_t but simply a 32-bit
int.

I don't mind changing it to 'int', even if it is only for historical
standard reasons, but I think that using a socklen_t, when prototyped
to void pointer, could generate unexpected problems when using strange
64-bit ABIs.

-- 
-=[Yang]=-