> 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.
My comment was not about having IPv6 working without addrinfo, but about not breaking platforms which don't have one. > I was looking for a feedback about this particular solution for > platforms that support IPv6. And feedback is "no, it's not the way it should be done, because we can't have different branches for platforms that have addrinfo and those which don't." > Supporting legacy platforms was not my primary goal _at this time_ Well, it is ours at all times and you have to respect that:-) Well, the goal is not really support legacy platform at all costs, but rather not discontinue if compatibility can be achieved by maintaining certain discipline. >> 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... > > 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. OK, to be absolutely sincere. It's not about what Microsoft [or RedHat] supports for the moment, but about exercising above mentioned discipline. It's not about looking for excuses, but exploring maximum possible extent of portability. Is it possible to write code which adapts itself to run-time environment? Regardless whether run-time is supported by vendor or not? How complicated is it? Forget that you're RedHat employee, become programmer instead:-) But this is getting off-topic. DSO_global_lookup was not the point I wanted to emphasize! DSO_global_lookup is mentioned only because you'll have to cope with it in HEAD branch. The main point is that changes of this character should be *conditional* for backward compatibility and you have to play by this rules. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
