James Carlson wrote: > Sebastien Roy wrote: > >> | inet_cidr_ntop | Volatile | Undocumented | >> | inet_cidr_ntop | Volatile | Undocumented | >> | inet_nsap_addr | Volatile | Undocumented | >> | inet_nsap_ntoa | Volatile | Undocumented | >> | inet_cidr_pton | Volatile | Documented[5] | >> | inet_neta | Volatile | Documented[5] | >> > > Why are those last two treated the same as the others? They appear to > be intended to be used as programming interfaces by ordinary > applications, and seem to be useful interfaces. Why should they be > marked as "Volatile?" Are they in fact likely to change in incompatible > ways? > One goal of this project is to move closer to ISC source base and make merging and updating easier. Since ISC does not guarantee that these interfaces will not change in incompatible ways we do not want to make that guarantee. > >> Even though ISC defines the above interfaces in public header files it does >> not >> provide any documentation for most of the interfaces. We can not guarantee >> the semantics and hence we are making no attempt to document these functions. >> This is similar to what was done in previous update PSARC 1999/662. >> > > That case isn't publicly visible, but at least with the BIND server > cases, I recall that we intentionally segregated the interfaces based on > how they were documented upstream -- treating undocumented interfaces > and those documented not to be used as Volatile (or worse), and the rest > as Uncommitted or better. > > Does Volatile really match with the upstream behavior and the downstream > usage? Or is it just a replay of "external?" > I am not aware of any ISC interface classification scheme, so how was it figured out which interfaces ISC will not change. In fact ISC has changed some interfaces in incompatible ways and for this update we have to implement workarounds to provide backward compatibility and we do not want to keep doing that. Your assumption about volatile being a replay on external is correct.
Rao.
