Approach to sin_zero

Discussion in 'C++' started by woodbrian77@gmail.com, Oct 9, 2012.

  1. Guest

    Shalom

    Is the memset below needed? Stevens says sin_zero is
    not used. Others on the newsgroups say clearing the field
    is needed on a few platforms. I've left the memset in just
    to be on the safe side.

    sock_type cmw::udp_server (uint32_t port)
    {
    sock_type sd = getSocket(SOCK_DGRAM);
    sockaddr_in si_me;
    si_me.sin_family = AF_INET;
    si_me.sin_port = htons(port);
    si_me.sin_addr.s_addr = htonl(INADDR_ANY);
    ::std::memset(&si_me.sin_zero, 0, sizeof(si_me.sin_zero));
    if :):bind(sd, (sockaddr*) &si_me, sizeof(si_me))==-1) {
    throw failure("udp Bind errno: ") << GetError();
    }
    return sd;
    }

    Thanks in advance.

    Ebenezer Enterprises -- making programming fun again.
    http://webEbenezer.net
     
    , Oct 9, 2012
    #1
    1. Advertising

  2. Melzzzzz Guest

    On Mon, 8 Oct 2012 18:58:53 -0700 (PDT)
    wrote:

    > Shalom
    >
    > Is the memset below needed? Stevens says sin_zero is
    > not used. Others on the newsgroups say clearing the field
    > is needed on a few platforms. I've left the memset in just
    > to be on the safe side.
    >
    > sock_type cmw::udp_server (uint32_t port)
    > {
    > sock_type sd = getSocket(SOCK_DGRAM);
    > sockaddr_in si_me;
    > si_me.sin_family = AF_INET;
    > si_me.sin_port = htons(port);
    > si_me.sin_addr.s_addr = htonl(INADDR_ANY);
    > ::std::memset(&si_me.sin_zero, 0, sizeof(si_me.sin_zero));
    > if :):bind(sd, (sockaddr*) &si_me, sizeof(si_me))==-1) {
    > throw failure("udp Bind errno: ") << GetError();
    > }
    > return sd;
    > }
    >


    Quick google search shows that on mac OS X it is needed.
    Perhaps on Free BSD, too.

    Anyway, I always initialize whole struct to zero prior
    filling fields ;)
     
    Melzzzzz, Oct 9, 2012
    #2
    1. Advertising

  3. Ian Collins Guest

    On 10/09/12 14:58, wrote:
    > Shalom
    >
    > Is the memset below needed? Stevens says sin_zero is
    > not used. Others on the newsgroups say clearing the field
    > is needed on a few platforms. I've left the memset in just
    > to be on the safe side.


    While somewhat OT, a couple of points:

    > sock_type cmw::udp_server (uint32_t port)
    > {
    > sock_type sd = getSocket(SOCK_DGRAM);
    > sockaddr_in si_me;


    Why not just write

    sockaddr_in si_me = {0};

    and leave it at that?

    > si_me.sin_family = AF_INET;
    > si_me.sin_port = htons(port);


    What happens if post is too big for a uint16_t? In other words, why is
    the parameter type a uint32_t?

    > si_me.sin_addr.s_addr = htonl(INADDR_ANY);
    > ::std::memset(&si_me.sin_zero, 0, sizeof(si_me.sin_zero));
    > if :):bind(sd, (sockaddr*)&si_me, sizeof(si_me))==-1) {
    > throw failure("udp Bind errno: ")<< GetError();
    > }
    > return sd;
    > }


    --
    Ian Collins
     
    Ian Collins, Oct 9, 2012
    #3
  4. Jorgen Grahn Guest

    On Tue, 2012-10-09, wrote:
    > Shalom
    >
    > Is the memset below needed? Stevens says sin_zero is
    > not used. Others on the newsgroups say clearing the field
    > is needed on a few platforms. I've left the memset in just
    > to be on the safe side.
    >
    > sock_type cmw::udp_server (uint32_t port)
    > {
    > sock_type sd = getSocket(SOCK_DGRAM);
    > sockaddr_in si_me;
    > si_me.sin_family = AF_INET;
    > si_me.sin_port = htons(port);
    > si_me.sin_addr.s_addr = htonl(INADDR_ANY);
    > ::std::memset(&si_me.sin_zero, 0, sizeof(si_me.sin_zero));
    > if :):bind(sd, (sockaddr*) &si_me, sizeof(si_me))==-1) {
    > throw failure("udp Bind errno: ") << GetError();
    > }
    > return sd;
    > }


    Is there a reason you don't use POSIX getaddrinfo(3)? It handles those
    things for you, takes care of IPv4/IPv6, and is described in Stevens'
    books.

    Followup set.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 9, 2012
    #4
  5. Guest

    On Monday, October 8, 2012 10:20:33 PM UTC-5, Ian Collins wrote:
    >
    > What happens if post is too big for a uint16_t? In other words, why is
    >
    > the parameter type a uint32_t?
    >
    >


    That's probably laziness and I'll check on
    changing it.
     
    , Oct 9, 2012
    #5
  6. Guest

    On Tuesday, October 9, 2012 10:21:33 AM UTC-5, Jorgen Grahn wrote:
    >
    > Is there a reason you don't use POSIX getaddrinfo(3)? It handles those
    >
    > things for you, takes care of IPv4/IPv6, and is described in Stevens'
    >
    > books.
    >
    >


    I'm using getaddrinfo elsewhere, but it hadn't
    occurred to me to use it here.

    >
    > Followup set.
    >
    >


    What does that mean?
     
    , Oct 9, 2012
    #6
  7. On 10/9/2012 11:52 AM, wrote:
    > On Tuesday, October 9, 2012 10:21:33 AM UTC-5, Jorgen Grahn wrote:
    >> [..]
    >> Followup set.
    >>
    >>

    >
    > What does that mean?


    That means that if you used a real newsreader, the reply would
    automatically be addressed to another newsgroup, in this case
    'comp.protocols.tcp-ip', which Jorgen probably recommends for this
    discussion (instead of c.l.c++). Of course the newsgroup for the reply
    can always be overridden, but it requires conscious effort (IOW using
    one's brain)...

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 9, 2012
    #7
  8. Jorgen Grahn Guest

    On Tue, 2012-10-09, Victor Bazarov wrote:
    > On 10/9/2012 11:52 AM, wrote:
    >> On Tuesday, October 9, 2012 10:21:33 AM UTC-5, Jorgen Grahn wrote:
    >>> [..]
    >>> Followup set.
    >>>
    >>>

    >>
    >> What does that mean?

    >
    > That means that if you used a real newsreader, the reply would
    > automatically be addressed to another newsgroup,


    Yes, and I'm surprised that Google ignores it. I knew they were a pain
    on Usenet, but not that they were *that* arrogant.

    But I should have written "Followup-to set to comp.protocols.tcp-ip"
    for clarity.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 9, 2012
    #8
  9. Guest

    Here's a version that uses getaddrinfo:

    sock_type cmw::udp_server (uint16_t port)
    {
    ::std::eek:stringstream out;
    out << port;

    addrinfo* res;
    addrinfo hints;
    ::std::memset(&hints, 0, sizeof(hints));
    hints.ai_family = AF_UNSPEC;
    hints.ai_socktype = SOCK_DGRAM;
    hints.ai_flags = AI_PASSIVE;

    int err;
    if ((err = ::getaddrinfo(nullptr
    , out.str().c_str()
    , &hints
    , &res
    )) != 0) {
    throw failure("udp_server getaddrinfo: ") << gai_strerror(err);
    }

    sock_type sd = getSocket(SOCK_DGRAM);
    if :):bind(sd, res->ai_addr, res->ai_addrlen)==-1) {
    throw failure("udp_server bind: ") << GetError();
    }
    return sd;
    }

    The unfortunate thing is the change adds over 2,000 bytes
    to an executable. It isn't a big executable and the
    percentage increase is close to 3%. That strikes me as
    excessive. Are there any other alternatives?
     
    , Oct 10, 2012
    #9
  10. Guest

    On Tuesday, October 9, 2012 9:47:21 PM UTC-4, (unknown) wrote:

    >
    > Are there any other alternatives?


    Does it work to change

    si_me.sin_family = AF_INET;

    to

    si_me.sin_family = AF_UNSPEC;

    in the function I originally posted?

    It looks like there are people doing that out there,
    but I couldn't find anything that says it is valid.
     
    , Oct 10, 2012
    #10
  11. Ian Collins Guest

    On 10/10/12 14:47, wrote:
    > Here's a version that uses getaddrinfo:
    >
    > sock_type cmw::udp_server (uint16_t port)
    > {
    > ::std::eek:stringstream out;
    > out<< port;
    >
    > addrinfo* res;
    > addrinfo hints;
    > ::std::memset(&hints, 0, sizeof(hints));


    Why do you call memset?

    addrinfo hints = {0};

    Is more concise.

    > hints.ai_family = AF_UNSPEC;
    > hints.ai_socktype = SOCK_DGRAM;
    > hints.ai_flags = AI_PASSIVE;
    >
    > int err;
    > if ((err = ::getaddrinfo(nullptr
    > , out.str().c_str()
    > ,&hints
    > ,&res
    > )) != 0) {
    > throw failure("udp_server getaddrinfo: ")<< gai_strerror(err);
    > }
    >
    > sock_type sd = getSocket(SOCK_DGRAM);
    > if :):bind(sd, res->ai_addr, res->ai_addrlen)==-1) {
    > throw failure("udp_server bind: ")<< GetError();
    > }
    > return sd;
    > }
    >
    > The unfortunate thing is the change adds over 2,000 bytes
    > to an executable. It isn't a big executable and the
    > percentage increase is close to 3%. That strikes me as
    > excessive. Are there any other alternatives?


    Try comp.unix.programmer.

    --
    Ian Collins
     
    Ian Collins, Oct 10, 2012
    #11
  12. Ian Collins Guest

    On 10/10/12 15:06, wrote:
    > On Tuesday, October 9, 2012 9:47:21 PM UTC-4, (unknown) wrote:
    >
    >>
    >> Are there any other alternatives?

    >
    > Does it work to change
    >
    > si_me.sin_family = AF_INET;
    >
    > to
    >
    > si_me.sin_family = AF_UNSPEC;
    >
    > in the function I originally posted?
    >
    > It looks like there are people doing that out there,
    > but I couldn't find anything that says it is valid.


    Try comp.unix.programmer.
    --
    Ian Collins
     
    Ian Collins, Oct 10, 2012
    #12
  13. Guest

    On Tuesday, October 9, 2012 10:07:55 PM UTC-4, Ian Collins wrote:
    >
    >
    > Why do you call memset?
    >
    >
    >
    > addrinfo hints = {0};
    >
    >
    >
    > Is more concise.
    >


    Thanks. I started using that now, but it didn't
    affect the size of the executable.
     
    , Oct 10, 2012
    #13
  14. Guest

    To go a little further with this ... everything seems
    to be working fine on Linux. And if the middle tier is
    running on Linux and the front tier on Windows things
    work fine. But if both the middle and front tiers are
    running on Windows, I get a 10054 -- port unreachable
    error. I'm not sure if this indicates a problem in the
    networking code that I've been working on. If there is
    a problem, the above seems to indicate it is with the
    middle tier which is a udp server.

    addrinfo* cmw::getaddrinfo_wrapper(char const * node
    , int port
    , int flags
    , int socktype
    )
    {
    ::std::eek:stringstream out;
    out << port;

    addrinfo* res;
    addrinfo hints = {0};
    hints.ai_flags = flags;
    hints.ai_family = AF_UNSPEC;
    hints.ai_socktype = socktype;

    int err;
    if ((err = ::getaddrinfo(node
    , out.str().c_str()
    , &hints
    , &res
    )) != 0) {
    throw failure("Getaddrinfo: ") << gai_strerror(err);
    }
    return res;
    }


    sock_type cmw::udp_server (uint16_t port)
    {
    addrinfo* res = getaddrinfo_wrapper(nullptr
    , port
    , AI_PASSIVE
    , SOCK_DGRAM
    );
    sock_type sd = getSocket(res->ai_family, SOCK_DGRAM);
    if :):bind(sd, res->ai_addr, res->ai_addrlen)==-1) {
    throw failure("udp_server bind: ") << GetError();
    }
    ::freeaddrinfo(res);
    return sd;
    }

    Netstat on windows shows this
    UDP [::]:55555 *:*

    which is the port number I expect it to use.

    I guess it could be a Windows problem, but am not
    really sure. All of the code is here --
    http://webEbenezer.net/build_integration.html
    ..
     
    , Oct 12, 2012
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. KavvY
    Replies:
    1
    Views:
    400
  2. valentin tihomirov
    Replies:
    9
    Views:
    2,513
    Ray Andraka
    Apr 15, 2004
  3. Wiener, Norbert
    Replies:
    4
    Views:
    590
    Jerry Avins
    Nov 18, 2004
  4. les
    Replies:
    1
    Views:
    357
    Elliot Rodriguez
    Jul 31, 2003
  5. Mr Gordonz

    Advice on design approach and principles

    Mr Gordonz, Aug 4, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    369
    Steve C. Orr, MCSD
    Aug 4, 2003
Loading...

Share This Page