Rémi Denis-Courmont writes: > All of this four fields are integer and hence valid candidates for > memory coypying,
Isn't setting ai_flags to a value provided to you by someone else, but that contains bits you don't understand, essentially equivalent to setting arbitrary undefined bits? I think the point is that copying isn't very safe. > So there is a known, if minor, problem, and a very low cost solution: > Two new APIs and one struct (there are >1000 anyway). Also, > generic/system-wide source address selection should and will be relied > upon by most software. IMHO, better put the burden on those that use > it, than on everything else. I don't see how a new API will help. Won't the old code still use the old interface but with the new bits provided by the new application? There's no way that the application can know that the library calls getaddrinfo instead of geteaddrinfo (or some such). If you create a different struct and make sure that such an application would fail to compile properly (can't compile against the old headers, and can't run-time link because you need the new library), that might work. Conservative implementations might rename the interface anyway (using #define or redefine_extname or similar) and force the unknown bits off. That'd produce a different set of breakage, but at least produces obvious results and doesn't require a different API. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
