On 2005-07-31, Oliver Jowett <oliver@opencloud.com> wrote:
> I'm not worried about changing values; I think that representing the
> "option level" as an IP protocol number, in an interface that
> encompasses non-IP protocols, is a bad API design decision.
The interpretation of that parameter, if not equal to SOL_SOCKET, is
clearly protocol-dependent and therefore driven by the protocol family of
the socket.
> If the rule for setsockopt is "pass the IP protocol number as the level
> argument", then what value should I pass to manipulate, say,
> X.25-specific settings on an X.25 socket?
The rule is "pass whatever value the socket's protocol family expects".
For IP that happens to be an IP protocol number. For other families it
is some constant meaningful to that family.
> In practice you use a synthetic value which is outside the range of
> valid IP protocols.
No, you don't. There is no assumption that socket level parameters form
a single namespace (with the exception of SOL_SOCKET which is common to
all protocol families).
> getprotoent() won't know about this value
getprotoent() is specific to the INET address family and makes no attempt
to pretend to support anything else (if it did, it'd need to take an AF_*
parameter to disambiguate between families).
>> Also, that assignment is not mere BSD-ism, it's specified by the Single
>> Unix Spec, as well as every other document I could lay my hands on
>> today. Whoever wrote the comments in linux/socket.h is just
>> clueless.
>
> That seems a bit unfair, the comment is accurate (the SOL_* constants do
> need to match the protocol number assignments for compatibility with
> code that expects the BSD behaviour) and might even predate SUS.
It's based on a fundamental misunderstanding that SOL_* constants other than
SOL_SOCKET should even exist and that they form a namespace (which they do
not).
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services