Okay, That makes complete sense. I would be completely happy with returning something from CURLOPT_SOCKOPTFUNCTION to indicate I do not want libcurl to try and connect the socket.
Sorry for the misunderstanding. Cheers, Keean. On 8 February 2011 22:09, Daniel Stenberg <[email protected]> wrote: > On Mon, 7 Feb 2011, Keean Schupke wrote: > > Can't we instead add a new return code to the CURLOPT_SOCKOPTFUNCTION >>> >> >> The OPENSOCKETFUNCTION returns the socket as its return value, so unless a >> structure is returned then I don't see how this can easily be done. >> > > Now, if you look again you'll see that we're not talking about the same > callback function... > > > We could test the socked with "getpeername" to see if it is connected? If >> getpeername(...) returns an error the socket is not connected. Something >> like: >> >> if (getpeername(socket, &addr, len) < 0) { >> rc = connect(socket, &addr, len); >> } >> > > Right, but that too adds assumptions that the socket is connected in a way > I rather avoid. If we want to allow the app to provide a file descriptor, I > would like to make as few assumptions as possible about what the nature of > that descriptor is (and requirements of what it has to be). It doesn't have > to be a TCP based socket for all I care... > > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html >
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
