Hello Rémi, Thanks for your time reviewing V04 of the address selection API. Julien L. has already addressed your comments. Here are some additional comments.
The proposed solution of extending the getaddrinfo structure (at the end) is designed to keep ABI consistency in mind. The extended ai_eflags will not break ABI boundaries unless the library design is broken. Usually libraries maintain versions for binary compatibility reasons and new programs with newer data structure should be compiled for the new library version. The old application will run fine with the new library as they have not used the extended flags. On the otherhand, the old library should not recognize AI_PREFERENCES as a valid flag. Thus, your concern on ABI compatibility is not a practical one. Thanks for the thorough reviewing though. Regards, -Samita
> One goal of this API is to be preserve the existing > basic IPv6 socket API. Expanding a structure breaks the API already. > Besides, I don't understand how would ai_connaddr and > ai_bindaddr solve the issue you describe. It makes sure the source address that will actually be bound in the one that was selected by getaddrinfo(). > It should never be assumed (by application, library > kernel...) that the ai_eflags field is present in a > struct addrinfo if the struct doesn't have the > AI_PREFERENCES flag set in its ai_flags field. IMHO, that's an ugly hack. It breaks the ABI. > Hence a buffer overflow shouldn't happen unless the > library of you scenario is broken. Sure, but that does not solve my problem. In fact buffer overflow will happen in even less obvious ways. If some function compiled against the new ABI memset() an addrinfo pointer to a structure allocated by a function built with the old ABI, you have a buffer overflow, and well, you can't test for AI_PREFERENCES, since you don't even know it exists. Very bad idea. Changing a struct storage size is always a very bad idea. Why do you think people invented struct sockaddr_storage instead of increasing the size of struct sockaddr when rolling out the IPv6 API? > > IMHO, it might be wiser to define extended > > getaddrinfo, freeaddrinfo and struct addrinfo > > variants (geteaddrinfo ?) - that woud allow to use > > the ai_bindaddr and ai_connaddr thing at the same > > time. > IMHO it's nice to avoid introducing yet another name > resolution primitive. Regarding ai_bindaddr and > ai_connaddr, see my comment above. I don't see any point in sparing extra primitive and structure names. I think that it is much nicer than partially breaking the ABI by changing the size of structure. -- Rémi Denis-Courmont
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
