You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jon Travis <jt...@p00p.org> on 2001/04/30 19:39:52 UTC
[PATCH] socket family fetching
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.
Index: include/apr_network_io.h
===================================================================
RCS file: /home/cvspublic/apr/include/apr_network_io.h,v
retrieving revision 1.101
diff -u -u -r1.101 apr_network_io.h
--- include/apr_network_io.h 2001/04/03 01:09:51 1.101
+++ include/apr_network_io.h 2001/04/30 16:31:30
@@ -596,6 +596,16 @@
apr_sockaddr_t *sockaddr);
/**
+ * Return the family in an APR socket address.
+ * @param family The family from the socket address.
+ * @param sockaddr The socket address to reference.
+ * @deffunc apr_status_t apr_sockaddr_family_get(apr_int32_t *family, apr_sockaddr_t *sockaddr)
+ */
+APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
+ apr_sockaddr_t *sockaddr);
+
+
+/**
* Set the IP address in an APR socket address.
* @param sockaddr The socket address to use
* @param addr The IP address to attach to the socket.
Index: network_io/unix/sa_common.c
===================================================================
RCS file: /home/cvspublic/apr/network_io/unix/sa_common.c,v
retrieving revision 1.32
diff -u -u -r1.32 sa_common.c
--- network_io/unix/sa_common.c 2001/03/15 21:54:59 1.32
+++ network_io/unix/sa_common.c 2001/04/30 16:32:07
@@ -114,6 +114,21 @@
return APR_SUCCESS;
}
+APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
+ apr_sockaddr_t *sockaddr)
+{
+ if(sockaddr->salen == sizeof(struct sockaddr_in))
+ *family = APR_INET;
+#if APR_HAVE_IPV6
+ else if(sockaddr->salen == sizeof(struct sockaddr_in6))
+ *family = APR_INET6;
+#endif
+ else
+ *family = APR_UNSPEC;
+
+ return APR_SUCCESS;
+}
+
APR_DECLARE(apr_status_t) apr_sockaddr_ip_get(char **addr,
apr_sockaddr_t *sockaddr)
{
Re: [PATCH] socket family fetching
Posted by Jon Travis <jt...@p00p.org>.
This is also fine by me. As long as I can get the family easily, and
don't have to check 'well am I in ipv6? yes? ok, gotta go to sin6', etc.
-- Jon
On Mon, Apr 30, 2001 at 08:57:16PM -0400, Jeff Trawick wrote:
> rbb@covalent.net writes:
>
> > +1 for the socket family function that Jon posted earlier today. Unless
> > somebody objects, I'll commit it tonight.
>
> I don't think we want accessor functions for everything
> within as well as the iterator function. A plain family field in
> apr_sockaddr_t keeps everybody happy. (call it "-0" :) )
>
> If you commit something, I think that addr->sa.sin.sin_family should
> have the right value and would result in simpler logic.
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
Re: [PATCH] socket family fetching
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> +1 for the socket family function that Jon posted earlier today. Unless
> somebody objects, I'll commit it tonight.
I don't think we want accessor functions for everything
within as well as the iterator function. A plain family field in
apr_sockaddr_t keeps everybody happy. (call it "-0" :) )
If you commit something, I think that addr->sa.sin.sin_family should
have the right value and would result in simpler logic.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] socket family fetching
Posted by rb...@covalent.net.
+1 for the socket family function that Jon posted earlier today. Unless
somebody objects, I'll commit it tonight.
Ryan
On 30 Apr 2001, 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 definitely vote for a routine to return the family from an
> apr_socket_t :)
>
> APR_DECLARE(apr_status_t) apr_socket_family_get(apr_int32_t *family,
> apr_socket_t *sock);
>
> apr_socket_t is opaque and you have to use a hokey way to find out the
> family currently. If we could get rid of that need then we could get
> rid of the usually-wasted apr_sockaddr_t allocated with the socket.
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] socket family fetching
Posted by Jeff Trawick <tr...@bellsouth.net>.
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 definitely vote for a routine to return the family from an
apr_socket_t :)
APR_DECLARE(apr_status_t) apr_socket_family_get(apr_int32_t *family,
apr_socket_t *sock);
apr_socket_t is opaque and you have to use a hokey way to find out the
family currently. If we could get rid of that need then we could get
rid of the usually-wasted apr_sockaddr_t allocated with the socket.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] socket family fetching
Posted by David Reid <dr...@jetnet.co.uk>.
Jeff and I talked about this when we added the IPv6 stuff (which included
the sockaddr types) and Jeff's feeling was to leave these functions and let
people access the details directly. I don't mind either approach...
david
----- Original Message -----
From: "Jon Travis" <jt...@p00p.org>
To: <de...@apr.apache.org>
Sent: Monday, April 30, 2001 6:39 PM
Subject: [PATCH] socket family fetching
> 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.
>
>
> Index: include/apr_network_io.h
> ===================================================================
> RCS file: /home/cvspublic/apr/include/apr_network_io.h,v
> retrieving revision 1.101
> diff -u -u -r1.101 apr_network_io.h
> --- include/apr_network_io.h 2001/04/03 01:09:51 1.101
> +++ include/apr_network_io.h 2001/04/30 16:31:30
> @@ -596,6 +596,16 @@
> apr_sockaddr_t *sockaddr);
>
> /**
> + * Return the family in an APR socket address.
> + * @param family The family from the socket address.
> + * @param sockaddr The socket address to reference.
> + * @deffunc apr_status_t apr_sockaddr_family_get(apr_int32_t *family,
apr_sockaddr_t *sockaddr)
> + */
> +APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
> + apr_sockaddr_t *sockaddr);
> +
> +
> +/**
> * Set the IP address in an APR socket address.
> * @param sockaddr The socket address to use
> * @param addr The IP address to attach to the socket.
> Index: network_io/unix/sa_common.c
> ===================================================================
> RCS file: /home/cvspublic/apr/network_io/unix/sa_common.c,v
> retrieving revision 1.32
> diff -u -u -r1.32 sa_common.c
> --- network_io/unix/sa_common.c 2001/03/15 21:54:59 1.32
> +++ network_io/unix/sa_common.c 2001/04/30 16:32:07
> @@ -114,6 +114,21 @@
> return APR_SUCCESS;
> }
>
> +APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
> + apr_sockaddr_t *sockaddr)
> +{
> + if(sockaddr->salen == sizeof(struct sockaddr_in))
> + *family = APR_INET;
> +#if APR_HAVE_IPV6
> + else if(sockaddr->salen == sizeof(struct sockaddr_in6))
> + *family = APR_INET6;
> +#endif
> + else
> + *family = APR_UNSPEC;
> +
> + return APR_SUCCESS;
> +}
> +
> APR_DECLARE(apr_status_t) apr_sockaddr_ip_get(char **addr,
> apr_sockaddr_t *sockaddr)
> {
Re: [PATCH] socket family fetching
Posted by 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...
Re: [PATCH] socket family fetching
Posted by 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
Posted by Jeff Trawick <tr...@bellsouth.net>.
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.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...