Socket descriptor 0 is invalid?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Socket descriptor 0 is invalid?

    Porting a simple application for BSD sockets we faced the following problem:

    the original code was an evergreen of socket programming:

    C Source Code

    1. sh = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

    this call returns a socket handle sh=0, which, according to embOS/IP documentation, is a valid handle, but subsequent calls to getsockopt() and setsockopt() return -1;

    We then discovered that the same example works replacing the socket creation code with:

    C Source Code

    1. sh = socket(AF_INET, SOCK_STREAM, 0);


    We suggest to treat internally any non-zero value passed as third parameter like a passed "0" to ease portings, otherwise we'll need to modify all socket() calls.
    Could you also clarify if sh=0 is a valid socket or not?

    Thanks
    Francesco

  • the original code was an evergreen of socket programming:

    C Source Code

    1. socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);


    this call returns a socket handle sh=0, which, according to embOS/IP documentation, is a valid handle, but subsequent calls to getsockopt() and setsockopt() return -1;

    We then discovered that the same example works replacing the socket creation code with:

    C Source Code

    1. socket(AF_INET, SOCK_STREAM, 0);


    We suggest to treat internally any non-zero value passed as third parameter like a passed "0" to ease portings, otherwise we'll need to modify all socket() calls.
    Could you also clarify if sh=0 is a valid socket or not?

    The returned socket handle is not valid. IPPROTO_TCP is an invalid value for the parameter Proto.
    The embOS/IP manual says clearly that the parameter Proto must be set to zero (embOS/IP User Guide, page 105, parameter description for the function socket()).

    I have changed the code of socket() to return SOCKET_ERROR if the parameter Proto is not zero.
    Replacing invalid values internally is not a good solution, since an internal correction of the parameter can possibly cause further problems in the application.

    The updated version will be ready by the end of this week.

    Best regards,
    Sven