Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> lot of APR's socket code is supposing that the socket is IP-based.
> I think that's completely bogus.
The only portable sockets are IP-based, for what that's worth. But it
isn't worth much if we want to add some non-portable flavor of socket.
> > > +#if APR_HAVE_UNIX_DOMAIN
> > > +#define APR_UNIX AF_UNIX
> > > +#endif
> >
> > Note that POSIX supposedly prefers AF_LOCAL to AF_UNIX. But we
> > already have APR_LOCAL :) (What about APR_SOCKET_INET,
> > APR_SOCKET_INET6, APR_SOCKET_LOCAL? Or better yet, AF_INET, AF_INET6,
> > AF_LOCAL? (Sorry, David))
>
> AF_LOCAL or PF_LOCAL aren't defined on Solaris. =)
doesn't matter
If APR will only support local sockets on Unix, I guess APR_UNIX is
okay, but otherwise I'd vote for keeping UNIX out of the name.
> I think there
> are some platforms that have removed AF_ and gone to PF_.
hard to believe... Most code uses AF_ so removing AF_ definitions
would cause great anguish at compile time.
> So, I
> think it might be good to keep some level of indirection.
>
> This leads me to believe that we should have an
> apr_sockaddr_set_path(...) function that hides these implementation
> details.
certainly...
(or maybe apr_sockaddr_path_set() to maintain our normal level of
confusion)
> > > + sock->local_addr->addr_str_len = 108;
> >
> > What about terminating '\0'? Maybe it should be sizeof(sun_path) + 1?
>
> The address is defined to be char[108] in every header file I can
> find, so this seems to be the magic number.
The main point is that even if sun_path was always 108 bytes, 108 is a
bug (no space for terminating '\0'). On the secondary point, if 108
looks better to you than the mumbo jumbo to get the size of sun_path,
then great :) But it isn't always 108, anyway.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
