Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 08 Sep 2001 05:47:09 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Bill Fenner <fenner@research.att.com>
Cc:        karels@bsdi.com, arch@freebsd.org
Subject:   Re: Causing <netinet/in.h> to depend on <sys/socket.h>
Message-ID:  <3B9A134D.3B31C443@mindspring.com>
References:  <200109072125.OAA25298@windsor.research.att.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner wrote:
> 
> Sorry for making people guess what I was talking about.
> 
> Concretely, http://www.ietf.org/internet-drafts/draft-ietf-idmr-msf-api-02.txt
> requires that #including <netinet/in.h> results in definitions like
> the following:
> 
> struct group_req {
>    uint32_t                gr_interface; /* interface index */
>    struct sockaddr_storage gr_group;     /* group address */
> };
> 
> struct group_source_req {
>    uint32_t                gsr_interface; /* interface index */
>    struct sockaddr_storage gsr_group;     /* group address */
>    struct sockaddr_storage gsr_source;    /* source address */
> };
> 
> struct group_filter {
>    uint32_t                gf_interface; /* interface index */
>    struct sockaddr_storage gf_group;     /* multicast address */
>    uint32_t                gf_fmode;     /* filter mode */
>    uint32_t                gf_numsrc;    /* number of sources */
>    struct sockaddr_storage gf_slist[1];  /* source address */
> };
> 
> Since they're not pointers, forward struct declarations don't work.


So... we didn't need these before, why do we now?

Why do they go in in.h?  Aren't they generic to all types of
sockaddr's, not just sockaddr_in's?

I don't see anyone using the things.  Unless they are being
used as other than a pointer, they don't need to have a real
type.


Also: this is a DRAFT RFC... if it requires this type of thing,
then it should probably be revised so that it _doesn't_ require
this type of thing in "draft-ietf-idmr-msf-api-03.txt" or
whatever the next version is... the thing expires in 3 months,
so it's arguable that it shouldn't be hitting anything other
than an experimentor's repository until it gets ratified as
experimental, and then makes it to standard's track, anyway.


I REALLY object to turning our header files into Linux's header
files, where if you include <machine/ansi.h>, all other include
files in the whole freaking system are dragged into your poor
compilation unit.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B9A134D.3B31C443>