BIND 10 #1452: add UDP socket passing to fd_X handling

[BIND 10 Development]

#1452: add UDP socket passing to fd_X handling
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   Priority:  major  |             Milestone:
                  Component:  DDNS   |  Sprint-20111220
                   Keywords:         |            Resolution:
            Defect Severity:  N/A    |             Sensitive:  0
Feature Depending on Ticket:  DDNS   |           Sub-Project:  DNS
        Add Hours to Ticket:  0      |  Estimated Difficulty:  5
                  Internal?:  0      |           Total Hours:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 vorner]:

 > > >  * Should the local includes be done first, before other headers, to
 ensure they don't use something from the system headers included above?
 > >
 > > Hmm, I don't know.  Is that a common practice?  I have no problem with
 > > reordering them that way if it's more common, but in that case I think
 > > we should rather make it in our project-wide guideline.  For now I've
 > > not make a change on this point.
 >
 > I met several projects doing so, and I use it on unconscious level
 already. We probably don't have it in guidelines, but IMO it makes some
 sense, as it makes sure the headers are stand-alone. Should I bring it to
 -dev?

 Yes, please.  For now I've not touched the ordering.  If we agree on
 the ordering there will be a cleanup ticket that will cover this one,
 too.

 > > You mean UNIX_MAX_PATH?  I thought it was not portable.
 >
 > I'm not sure about portability. I found it in my man page.

 At least they are not defined under /usr/include in FreeBSD or MacOS
 X.  So I still keep avoiding it.

 > > Maybe we should at least clarify the point?  e.g.
 > > {{{#!c++
 > >     // the copy should be safe due to the above check, but we'd be
 rather
 > >     // paranoid about making it 100% sure even if the check has a bug
 (with
 > >     // triggering the assertion in the worse case)
 > >     strncpy(impl.sock_un_.sun_path, unix_file.c_str(),
 > >             sizeof(impl.sock_un_.sun_path));
 > >     assert(impl.sock_un_.sun_path[sizeof(impl.sock_un_.sun_path) - 1]
 == '\0');
 > > }}}
 >
 > Yes, maybe.

 Added the comment.

 > > >  * Where does the magic number „2“ come from here?

 > Actually, I meant this 2:
 > {{{#!c++
 >     assert(impl.sock_un_.sun_path[sizeof(impl.sock_un_.sun_path) - 1] ==
 '\0');
 >     impl.sock_un_len_ = 2 + unix_file.length();
 > #ifdef HAVE_SA_LEN
 > }}}

 Oh, okay.  I meant this:
 {{{#!c++
     impl.sock_un_len_ = offsetof(struct sockaddr_un, sun_path) +
         unix_file.length();
 }}}
 I didn't know offsetof was defined in cstddef and might not be very
 portable...now I see it's part of cstddef, so I've updated the code
 using offsetof.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1452#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development