Rémi, First, please note that ABI does change with time, that's why we have APIs :)
Further, the new API does change the ABI, but it does not break backward ABI compatibility: - compile an old version of the library on an old system without the new API so that is conforms to the old ABI. - compile a piece of code on a old system without the new API so that it conforms to the old ABI. - link the piece of code conforming to the old ABI with a library conforming to the old ABI. - run the resulting old ABI-conforming binary on a new system with the new ABI: it works. Now what your example essentially does is: - compile an old library on an old system without the new API so that is conforms to the old ABI. - compile a piece of code on a new system with the new API so that it conforms to the new ABI. - link the piece of code conforming with the new ABI with a library conforming to an old ABI. Surprise: it breaks! Regarding the need for an application to save defaults if it want to restore them, I don't see that saving requirement as an issue. As we saw before, an application has already many things to save (e.g. save a value of the pointer to an addrinfo structure if it wants to free it :) --julien On Monday 12 March 2007 17:08, Rémi Denis-Courmont wrote: > Le lundi 12 mars 2007 11:31, Julien Laganier a écrit : > > An updated version of the IPv6 address selection > > API draft has been published (see below). Over the > > years, this draft has been reviewed by many > > participants to the IPv6 WG, and has been > > supported by many of them. Their feedback has been > > incorporated in successive revision of the draft. > > There are also serious implementers waiting for > > this draft to be published. > > This new version still breaks ABI compatibility, > meaning any implementors would have to rebuild any > software using getaddrinfo against a new library. > > This is an example code that shows one breakage > case: ai_eflags gets an undefined value. You simply > cannot change the size of a known structure in C > APIs (unless you pass a size value, such as bind() > and connect() do). > > http://www.remlab.net/files/divers/eaddr.c > > There are use-case for this; I DO know applications > using this kind of construct. > > To avoid this, either a new API is defined (e.g. > geteaddrinfo with a struct eaddrinfo), or preference > flags are stored in ai_flags which still has more > than enough bits available for this purpose. > > > Also, what is the rationale for not following the > current practice of using -1 as the system default > for setsockopt, instead of requiring the application > to store the value? That only "kills" one bit, but > will allow for the corner-case race condition where > the local default has changed in-between, and > simplify implementors life a lot (there are so many > case where you just pass socket handles through > different layers, and simply cannot pass anything > else without large changes). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
