Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

[Rémi Denis-Courmont <rdenis at simphalempin dot com>]

	Hello,

On Thu, Nov 09, 2006 at 07:45:29PM -0800, Samita Chakrabarti wrote :
> 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.

I cannot agree with you. Changing "sizeof (struct addrinfo)" will break
code that was properly designed against the old API.

Just imagine you have some library function that looks like:

int my_getaddrinfo (const char *server, const struct addrinfo *hints,
...)
{
	struct addrinfo modified_hints;
	/* ... */
	memcpy (&modified_hints, hints, sizeof (hints));
	modified_hints.ai_flags |= AI_V4MAPPED;
	/* ... */
}

Now imagine that this function is compiled against a newer C library
that would include your API *and ABI* change, but the caller is not
recompiled. The hints structure will be sized to the old struct
addrinfo, but the memcpy will try to copy it as if it had the new bigger
size, and well, that's of course pretty.

We might not have the same definition of ABI compatibility, but to me,
changing the size of a public structure is an incompatible ABI change.

> Thus, your concern on ABI compatibility is not a practical one.

I know code that is correct nowadays and will become incorrect with the
proposed changes.

I'd like to have external opinions on this... maybe I'm wrong afterwall.
glibc anyone?

-- 
Rémi Denis-Courmont