Re: [PATCH] socket family fetching

[Jon Travis <jt...@p00p.org>]

On Mon, Apr 30, 2001 at 05:58:30PM -0400, Jeff Trawick wrote:
> Jon Travis <jt...@p00p.org> writes:
> 
> > I need a routine to fetch the socket family.  I could just refer
> > to the information in the sockaddr_t address length, but that is
> > rather hackish.  Anyway, here tis.  We should also probably be
> > moving towards making the sockaddr_t an opaque type, or at least
> > some of the members.
> 
> I think that the better place to look is addr->sa.sin.sin_family.
> Hopefully you should be able to return this as-is.
> 
> On first thought, the partial opaqueness makes sense (though I don't
> know how to do that neatly in C).  Thinking down the road, the number
> of accessor functions could get out of hand (similar to the
> apr_fileinfo_t issue).  I'm mostly happy with apps peering into the
> apr_sockaddr_t, though maybe we need to make it friendlier by adding
> (e.g.) a family field which starts out as APR_UNSPEC and is set once
> we know the family.

Just do like so:

(in apr_network_io.h)
typedef struct apr_sockaddr_priv_t apr_sockaddr_priv_t;
struct apr_sockaddr_t {
	apr_pool_t *pool;,
	...
	apr_sockaddr_priv_t *privdata;
};

Then define apr_sockaddr_priv_t in either a header local only to the 
subdirectories (network_io, etc.) or simply define the members in the 
actual C file that uses it.  

Poking about in the sockaddr_in is kinda fun and easy to do, but is really
going to let people shoot themselves fairly easily, I fear.

-- Jon

Re: [PATCH] socket family fetching

[Jeff Trawick <tr...@bellsouth.net>]

Jon Travis <jt...@p00p.org> writes:

> Just do like so:
> 
> (in apr_network_io.h)
> typedef struct apr_sockaddr_priv_t apr_sockaddr_priv_t;
> struct apr_sockaddr_t {
> 	apr_pool_t *pool;,
> 	...
> 	apr_sockaddr_priv_t *privdata;
> };

I figured that part out :)  I thought you meant having two
definitions, one with "char[xyz] reserved;".

> Poking about in the sockaddr_in is kinda fun and easy to do, but is really
> going to let people shoot themselves fairly easily, I fear.

Are you worried about information they shouldn't have access to or
information they can't get to reliably?

potential problem areas:

. non-portable sin[6]_len (not needed since we have salen field)
. sin[6]_port maybe, if some weird system puts them in different
  places (solvable by filling in the port field; we should be doing
  this already)
. sin_family (not unsafe, just a little hokey; solvable by adding a
  family field) 
. ???

If it is opaque we need an iterator function (apr_sockaddr_info_get()
technically returns a linked list) and some way to get the whole
sockaddr and some way to get the ip address (but that is easy since
there is ipaddr_ptr and ipaddr_len) and some way to get the port
(maybe we should actually set the port field :) ) and potentially some
way to get to other things like sin6_flowinfo.

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...