Hello, This is all a matter of being consistent with the Advanced IPv6 API, and with the established practice in POSIX world. Pretty much every setsockopt uses int, unless it has very peculiar reason not to do so. Using something else will only confuse people, and add a (minor) extra implementation burden on implementors.
This is bound to cause problem. I'm pretty confident some people will use int regardless and well, too bad. On Thu, Oct 26, 2006 at 06:24:18AM +0200, Julien Laganier wrote : > I don't think we discussed that already on the ML. > > What we discussed however is to restore system default > by passing the value zero, and the draft does not use > that method because it is problematic; quoting Erik: This only works if you assume 0 is the default value. > > The issue is that we want the semantics of a > > setsockopt that doesn't include any of a X and a > > not-X pair not to affect the X-related setting. For > > instance, a setsockopt that only specifies Y (or Y| > > not-Z) shouldn't affect X. With that approach the > > logical effect of a setsockopt with no flags set > > (zero) must be a no-op. Thus it would be very odd to > > define that no flags set (i.e. zero) has some other > > semantics. > > Now if I consider your proposal of passing -1 as a > method to restore system defaults, that would mean > that all bits in the flags set bitstring are set to 1, > i.e. all possible flags are set. Though you should never use the sign bit to store any flag anyway, so it is not at all ambiguous. The hop limit and traffic class setsockopt already uses this model. When 0 is a legal value, it's not quite correct to assume that will be the "reset to default" as well > I don't think it is semantically clean to affect a > "restore system default" semantic to a flag set with > all possible flags set. Therefore it would probably be > required to reserve that semantic to the sign bit, and > don't use it for encoding any address preference flag. I do think it is semantically clean to use an "impossible" value as restore to system default, while it is NOT clean to use a "possible" value for that. The IETF thought otherwise in may 2003. Have you had a look at RFC3542 at all? (hint: §6.3 and §6.5) -- Rémi Denis-Courmont looking for a job http://www.simphalempin.com/home/infos/CV-en.pdf -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
