From owner-freebsd-current  Tue Apr  2 03:39:26 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id DAA08134
          for current-outgoing; Tue, 2 Apr 1996 03:39:26 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA08115
          Tue, 2 Apr 1996 03:39:10 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA11042; Tue, 2 Apr 1996 21:27:47 +1000
Date: Tue, 2 Apr 1996 21:27:47 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604021127.VAA11042@godzilla.zeta.org.au>
To: FreeBSD-Current@freebsd.org, gpalmer@freebsd.org
Subject: Re: Linker sets & structures for networking code
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>There seems to be something fundamentally WRONG in some of the
>networking stuff which I'm not sure how to fix. (I'm going through
>LINT trying to fix as many warnings as I can).

>People have noticed warnings like:

>../../kern/uipc_proto.c:62: warning: initialization from incompatible pointer type

This is because of bad type puns in ancient (pre-STDC) networking code.
It has nothing to do with linker sets.

The correct fix isn't obvious.  Many incorrect fixes are obvious :-).  E.g.,
cast away the warnings.

>...
>Which brings me to another problem with this code. The first field of
>the `protosw' structure is:

>        short   pr_type;                /* socket type used for */

>Which (if I understand the way this works right - I haven't been able
>to backtrack through the networking code enough to verify this) is
>used to match the requested protocol type against available protocol
>types. Since (in uipc_proto.c) pr_type for the raw_* stuff is declared
>as `0', I can't see how raw_input ever gets call via the localsw
>array. (Infact there are several examples of `raw_input' being called
>which bypasses localsw totally). So why on earth is it there?!?

I didn't attempt to fix it because I don't completely understand the
calling sequences, in particular this point.  I think some of the
functions in the switches are only accessed through the switches for
protocols that we don't support.

Bruce