Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
>
>>per my linux/socket.h:
>
>
>>>/* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
>>>#define SOL_IP 0
>>>/* #define SOL_ICMP 1 No-no-no! Due to Linux :-) we cannot use SOL_ICMP=1 */
>>>#define SOL_TCP 6
>
>
>>(I won't get into why using wire-level-protocol constants for syscall
>>option numbering is a bad idea.. :)
>
>
> [ raised eyebrow... ] You think the wire protocol numbers are more
> likely to change than the syscall assignments? Consider the range of
> systems that each change would affect.
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.
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?
In practice you use a synthetic value which is outside the range of
valid IP protocols. getprotoent() won't know about this value and
there's no IPPROTO_ define for it -- just a SOL_ one. So, er, why were
you using IP protocol constants as levels again? A clear design would
have them as two separate namespaces even if they happened to share values.
> 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.
From a portability point of view, it certainly seems better to use
IPPROTO_* and I have no problem with doing that. It just grates at a
design level.
Anyway, this doesn't affect the patch one way or the other, which is why
I didn't really want to get into it in the first place..
-O
