Jon Travis <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
