On Thu, Jul 20, 2006 at 06:04:37PM +0200, Andy Polyakov via RT wrote: > > I want to point out that there is rudimentary IPv6 support in HEAD > already. Well, it depends on new DSO_global_lookup, but it's not the > point I want to emphasize.
It is a very good point. I didn't know about it and I look at it right now. > > I prepared new version of the patch. > > - struct sockaddr_in server,client; > + struct addrinfo *res, *res0, hints; > > Typically unacceptable. You think exclusively about your platform and > disregard the fact that there might be platform, which don't have struct > addrinfo declared. All such changes should be *conditional*. Switching > to generic struct sockaddr complemented with #ifdef EAI_FAMILY and > #ifdef AF_INTE6 seemed to be appropriate for HEAD. Is there reason to do > something different in 098? Not really. I sent a patch to provide a solution for platforms that have addrinfo. Basically, if you do not have addrinfo, you cannot expect IPv6 to work. I was looking for a feedback about this particular solution for platforms that support IPv6. Supporting legacy platforms was not my primary goal _at this time_ -- what I wanted were comments about the IPv6 functionality. It is clear that some conditional branching might be needed, but I'd prefer to focus on it once the target (IPv6 solution) is agreed on. > Then keep in mind our workflow. Functional changes go to HEAD, then and > only then possibility of backport to one or more stable branches is > considered. I personally would also allow for some time between commit > to HEAD and backport, so that some feedback can be gathered. May I suggest that this is added to the www.openssl.org webpages, so that even people outside of The OpenSSL Core and Development Team know that they should be always targeting HEAD, not the last released version? The problem with HEAD is that it is a moving target and slightly harder for people from outside to hit it. > For reference. As for DSO_global_lookup. It might appear dubious to Unix > programmer, but it's not as uncommon in Windows, when program is > compiled with one set of headers is linked with elder system library at > run-time. That's where DSO_global_lookup is expected to fill in. Of > course one also has to double-check that corresponding structures are > compatible (which was done) and do appropriate things if not (turned to > be unnecessary in given case). So that changes can be made conditional > even at run-time... A. As DSO_global_lookup is currently only used for getaddrinfo and freeaddrinfo -- is it really a problem on Windows? Microsoft seems to lists these functions as available and supported for all Windows versions that are currently supported by Microsoft. -- Jan Pazdziora ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
