On 8/17/22 9:19 AM, Gleb Smirnoff wrote:
John,
On Wed, Aug 17, 2022 at 09:04:08AM -0700, John Baldwin wrote:
J> > diff --git a/sys/netinet6/udp6_usrreq.c b/sys/netinet6/udp6_usrreq.c
J> > index a7bdfce97707..6a3ac2abd90b 100644
J> > --- a/sys/netinet6/udp6_usrreq.c
J> > +++ b/sys/netinet6/udp6_usrreq.c
J> > @@ -131,12 +131,18 @@ VNET_DEFINE(int, zero_checksum_port) = 0;
J> > SYSCTL_INT(_net_inet6_udp6, OID_AUTO, rfc6935_port, CTLFLAG_VNET |
CTLFLAG_RW,
J> > &VNET_NAME(zero_checksum_port), 0,
J> > "Zero UDP checksum allowed for traffic to/from this port.");
J> > +
J> > +
J> > +/* netinet/udp_usrreqs.c */
J> > +pr_abort_t udp_abort;
J> > +pr_disconnect_t udp_disconnect;
J> > +pr_send_t udp_send;
J> > +
J>
J> Oof, can you please put these in a header instead? <netinet/udp_var.h>
would seem to be
J> a good candidate.
I actually don't want to share these functions to anybody. Sometimes we are
in a situation when two compilation units are historically separated,
while they need to call into each other functions, which by design are private.
Putting them in a header doesn't really change that. Anyone can add a local
prototype and call it. Even better, they can add a _wrong_ prototype and
call it with the wrong arguments. Or more likely, if the original function
changes
then previously working code breaks and the compiler won't catch this. In this
specific case you mostly sidestep that due to using a typedef, but in general
the
wrong prototype problem is the reason to store prototypes in headers.
I'm not sure that "I don't trust other developers" is a valid reason to avoid
the
use of headers, or at least I'm not sure it outweighs "code breaks without
the compiler noticing in the future". I'd rather signpost it in the header
clarifying when it is allowed to be used (e.g. /* Shared between udp*_usrreq.c.
*/
or the like)
--
John Baldwin