How to get rid of warning C4244/C4267 conversion?











up vote
-2
down vote

favorite












Is it possible to get rid of compiler warnings trying to cast from SOCKET to int or from size_t to int using winsock2 functions like sendto, select etc? May there is a common approach? (Windows, MSVC15)



example:



C4267 conversion from 'size_t' to 'int', possible loss of data:



sendto(_socket, managedPtr, _bufferSize, NULL, PSOCKADDR(&_sockaddr), sizeof(_sockaddr))
____________________________________________________________~~~~~~~~~~~~~~



C4244 conversion from 'SOCKET' to 'int', possible loss of data:



select(_socket + 1, &readfds, nullptr, nullptr, GetTV())



_______~~~~~~~~~______________________________________










share|improve this question
























  • What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
    – Hristijan Gjorshevski
    Nov 19 at 15:20












  • You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
    – Smit Ycyken
    Nov 19 at 15:28










  • These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
    – Hans Passant
    Nov 19 at 15:42















up vote
-2
down vote

favorite












Is it possible to get rid of compiler warnings trying to cast from SOCKET to int or from size_t to int using winsock2 functions like sendto, select etc? May there is a common approach? (Windows, MSVC15)



example:



C4267 conversion from 'size_t' to 'int', possible loss of data:



sendto(_socket, managedPtr, _bufferSize, NULL, PSOCKADDR(&_sockaddr), sizeof(_sockaddr))
____________________________________________________________~~~~~~~~~~~~~~



C4244 conversion from 'SOCKET' to 'int', possible loss of data:



select(_socket + 1, &readfds, nullptr, nullptr, GetTV())



_______~~~~~~~~~______________________________________










share|improve this question
























  • What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
    – Hristijan Gjorshevski
    Nov 19 at 15:20












  • You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
    – Smit Ycyken
    Nov 19 at 15:28










  • These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
    – Hans Passant
    Nov 19 at 15:42













up vote
-2
down vote

favorite









up vote
-2
down vote

favorite











Is it possible to get rid of compiler warnings trying to cast from SOCKET to int or from size_t to int using winsock2 functions like sendto, select etc? May there is a common approach? (Windows, MSVC15)



example:



C4267 conversion from 'size_t' to 'int', possible loss of data:



sendto(_socket, managedPtr, _bufferSize, NULL, PSOCKADDR(&_sockaddr), sizeof(_sockaddr))
____________________________________________________________~~~~~~~~~~~~~~



C4244 conversion from 'SOCKET' to 'int', possible loss of data:



select(_socket + 1, &readfds, nullptr, nullptr, GetTV())



_______~~~~~~~~~______________________________________










share|improve this question















Is it possible to get rid of compiler warnings trying to cast from SOCKET to int or from size_t to int using winsock2 functions like sendto, select etc? May there is a common approach? (Windows, MSVC15)



example:



C4267 conversion from 'size_t' to 'int', possible loss of data:



sendto(_socket, managedPtr, _bufferSize, NULL, PSOCKADDR(&_sockaddr), sizeof(_sockaddr))
____________________________________________________________~~~~~~~~~~~~~~



C4244 conversion from 'SOCKET' to 'int', possible loss of data:



select(_socket + 1, &readfds, nullptr, nullptr, GetTV())



_______~~~~~~~~~______________________________________







c++ compiler-warnings winsock2






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 15:36

























asked Nov 19 at 15:13









Smit Ycyken

939919




939919












  • What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
    – Hristijan Gjorshevski
    Nov 19 at 15:20












  • You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
    – Smit Ycyken
    Nov 19 at 15:28










  • These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
    – Hans Passant
    Nov 19 at 15:42


















  • What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
    – Hristijan Gjorshevski
    Nov 19 at 15:20












  • You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
    – Smit Ycyken
    Nov 19 at 15:28










  • These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
    – Hans Passant
    Nov 19 at 15:42
















What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
– Hristijan Gjorshevski
Nov 19 at 15:20






What would happen if the return value of sendto which is size_t cannot be represented with an int? That is a narrowing conversion and has implementation defined behavior, hence the warning.
– Hristijan Gjorshevski
Nov 19 at 15:20














You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
– Smit Ycyken
Nov 19 at 15:28




You understood me wrong, I'm not talking about the return value of winsock2 functions. Its all about argument conversion and common approach with casting types to windows types or about using size_t in those functions correctly without warnings.
– Smit Ycyken
Nov 19 at 15:28












These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
– Hans Passant
Nov 19 at 15:42




These functions are ancient and date from much simpler times. Casting bufferSize to (int) is required to keep the compiler happy about it. Incrementing the socket is not valid.
– Hans Passant
Nov 19 at 15:42












2 Answers
2






active

oldest

votes

















up vote
0
down vote













sendTo: The compiler possibly warns you about this, because you try to build a 64 bit application. Thus, size_t would be a 64 bit wide type and int would be 32 bit at most. To resolve this try to cast the result explicitely to an int so the compiler knows this was intended. Also this function may be replaced by send as read here MSDN "The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send." so maybe check that too.



select: as MSDN states the first parameter is ignored but kept as compatibility to berkeley sockets. Apparently Microsoft wanted to provide easy code portability to UNIX systems and thus designed its API to fit the POSIX standard so code can almost just be copy pasted (with some slight changes obviously) Read more here. So if you use winsock2 Ignore this parameter and set it to 0 or whatever integer. If you want to port your App, copy your code and pass a file descriptor of a socket instead of 0.






share|improve this answer






























    up vote
    0
    down vote













    Yes, it's possible:



    SOCKET s;
    int i = static_cast<int>(s);


    For the functions taking an int just make sure your value isn't > std::numeric_limits<int>::max() and it should be ok to do static_cast<int>(value).



    sendto(_socket, managedPtr, _bufferSize, NULL,
    &_sockaddr, static_cast<int>(sizeof(_sockaddr)));

    select(static_cast<int>(_socket)+1, ...); // the nfds parameter is ignored on Windows





    share|improve this answer























    • In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
      – Smit Ycyken
      Nov 19 at 15:24










    • @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
      – Yastanub
      Nov 19 at 15:27










    • The first parameter should be set to the highest-numbered file descriptor plus 1.
      – Smit Ycyken
      Nov 19 at 15:31










    • No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
      – Ted Lyngmo
      Nov 19 at 15:36










    • @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
      – Smit Ycyken
      Nov 19 at 15:50











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377566%2fhow-to-get-rid-of-warning-c4244-c4267-conversion%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    sendTo: The compiler possibly warns you about this, because you try to build a 64 bit application. Thus, size_t would be a 64 bit wide type and int would be 32 bit at most. To resolve this try to cast the result explicitely to an int so the compiler knows this was intended. Also this function may be replaced by send as read here MSDN "The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send." so maybe check that too.



    select: as MSDN states the first parameter is ignored but kept as compatibility to berkeley sockets. Apparently Microsoft wanted to provide easy code portability to UNIX systems and thus designed its API to fit the POSIX standard so code can almost just be copy pasted (with some slight changes obviously) Read more here. So if you use winsock2 Ignore this parameter and set it to 0 or whatever integer. If you want to port your App, copy your code and pass a file descriptor of a socket instead of 0.






    share|improve this answer



























      up vote
      0
      down vote













      sendTo: The compiler possibly warns you about this, because you try to build a 64 bit application. Thus, size_t would be a 64 bit wide type and int would be 32 bit at most. To resolve this try to cast the result explicitely to an int so the compiler knows this was intended. Also this function may be replaced by send as read here MSDN "The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send." so maybe check that too.



      select: as MSDN states the first parameter is ignored but kept as compatibility to berkeley sockets. Apparently Microsoft wanted to provide easy code portability to UNIX systems and thus designed its API to fit the POSIX standard so code can almost just be copy pasted (with some slight changes obviously) Read more here. So if you use winsock2 Ignore this parameter and set it to 0 or whatever integer. If you want to port your App, copy your code and pass a file descriptor of a socket instead of 0.






      share|improve this answer

























        up vote
        0
        down vote










        up vote
        0
        down vote









        sendTo: The compiler possibly warns you about this, because you try to build a 64 bit application. Thus, size_t would be a 64 bit wide type and int would be 32 bit at most. To resolve this try to cast the result explicitely to an int so the compiler knows this was intended. Also this function may be replaced by send as read here MSDN "The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send." so maybe check that too.



        select: as MSDN states the first parameter is ignored but kept as compatibility to berkeley sockets. Apparently Microsoft wanted to provide easy code portability to UNIX systems and thus designed its API to fit the POSIX standard so code can almost just be copy pasted (with some slight changes obviously) Read more here. So if you use winsock2 Ignore this parameter and set it to 0 or whatever integer. If you want to port your App, copy your code and pass a file descriptor of a socket instead of 0.






        share|improve this answer














        sendTo: The compiler possibly warns you about this, because you try to build a 64 bit application. Thus, size_t would be a 64 bit wide type and int would be 32 bit at most. To resolve this try to cast the result explicitely to an int so the compiler knows this was intended. Also this function may be replaced by send as read here MSDN "The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send." so maybe check that too.



        select: as MSDN states the first parameter is ignored but kept as compatibility to berkeley sockets. Apparently Microsoft wanted to provide easy code portability to UNIX systems and thus designed its API to fit the POSIX standard so code can almost just be copy pasted (with some slight changes obviously) Read more here. So if you use winsock2 Ignore this parameter and set it to 0 or whatever integer. If you want to port your App, copy your code and pass a file descriptor of a socket instead of 0.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 19 at 16:25

























        answered Nov 19 at 16:19









        Yastanub

        475213




        475213
























            up vote
            0
            down vote













            Yes, it's possible:



            SOCKET s;
            int i = static_cast<int>(s);


            For the functions taking an int just make sure your value isn't > std::numeric_limits<int>::max() and it should be ok to do static_cast<int>(value).



            sendto(_socket, managedPtr, _bufferSize, NULL,
            &_sockaddr, static_cast<int>(sizeof(_sockaddr)));

            select(static_cast<int>(_socket)+1, ...); // the nfds parameter is ignored on Windows





            share|improve this answer























            • In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
              – Smit Ycyken
              Nov 19 at 15:24










            • @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
              – Yastanub
              Nov 19 at 15:27










            • The first parameter should be set to the highest-numbered file descriptor plus 1.
              – Smit Ycyken
              Nov 19 at 15:31










            • No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
              – Ted Lyngmo
              Nov 19 at 15:36










            • @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
              – Smit Ycyken
              Nov 19 at 15:50















            up vote
            0
            down vote













            Yes, it's possible:



            SOCKET s;
            int i = static_cast<int>(s);


            For the functions taking an int just make sure your value isn't > std::numeric_limits<int>::max() and it should be ok to do static_cast<int>(value).



            sendto(_socket, managedPtr, _bufferSize, NULL,
            &_sockaddr, static_cast<int>(sizeof(_sockaddr)));

            select(static_cast<int>(_socket)+1, ...); // the nfds parameter is ignored on Windows





            share|improve this answer























            • In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
              – Smit Ycyken
              Nov 19 at 15:24










            • @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
              – Yastanub
              Nov 19 at 15:27










            • The first parameter should be set to the highest-numbered file descriptor plus 1.
              – Smit Ycyken
              Nov 19 at 15:31










            • No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
              – Ted Lyngmo
              Nov 19 at 15:36










            • @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
              – Smit Ycyken
              Nov 19 at 15:50













            up vote
            0
            down vote










            up vote
            0
            down vote









            Yes, it's possible:



            SOCKET s;
            int i = static_cast<int>(s);


            For the functions taking an int just make sure your value isn't > std::numeric_limits<int>::max() and it should be ok to do static_cast<int>(value).



            sendto(_socket, managedPtr, _bufferSize, NULL,
            &_sockaddr, static_cast<int>(sizeof(_sockaddr)));

            select(static_cast<int>(_socket)+1, ...); // the nfds parameter is ignored on Windows





            share|improve this answer














            Yes, it's possible:



            SOCKET s;
            int i = static_cast<int>(s);


            For the functions taking an int just make sure your value isn't > std::numeric_limits<int>::max() and it should be ok to do static_cast<int>(value).



            sendto(_socket, managedPtr, _bufferSize, NULL,
            &_sockaddr, static_cast<int>(sizeof(_sockaddr)));

            select(static_cast<int>(_socket)+1, ...); // the nfds parameter is ignored on Windows






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 20 at 13:22

























            answered Nov 19 at 15:21









            Ted Lyngmo

            1,057112




            1,057112












            • In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
              – Smit Ycyken
              Nov 19 at 15:24










            • @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
              – Yastanub
              Nov 19 at 15:27










            • The first parameter should be set to the highest-numbered file descriptor plus 1.
              – Smit Ycyken
              Nov 19 at 15:31










            • No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
              – Ted Lyngmo
              Nov 19 at 15:36










            • @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
              – Smit Ycyken
              Nov 19 at 15:50


















            • In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
              – Smit Ycyken
              Nov 19 at 15:24










            • @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
              – Yastanub
              Nov 19 at 15:27










            • The first parameter should be set to the highest-numbered file descriptor plus 1.
              – Smit Ycyken
              Nov 19 at 15:31










            • No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
              – Ted Lyngmo
              Nov 19 at 15:36










            • @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
              – Smit Ycyken
              Nov 19 at 15:50
















            In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
            – Smit Ycyken
            Nov 19 at 15:24




            In select function, you need to increment socket(warning C4244), in other winsock2 functions common type for size is int instead of size_t - so on different builds x64/x86 there would be warning C4267.
            – Smit Ycyken
            Nov 19 at 15:24












            @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
            – Yastanub
            Nov 19 at 15:27




            @SmitYcyken MSDN states that the first parameter is ignored anyway so what is _socket+1 supposed to do?
            – Yastanub
            Nov 19 at 15:27












            The first parameter should be set to the highest-numbered file descriptor plus 1.
            – Smit Ycyken
            Nov 19 at 15:31




            The first parameter should be set to the highest-numbered file descriptor plus 1.
            – Smit Ycyken
            Nov 19 at 15:31












            No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
            – Ted Lyngmo
            Nov 19 at 15:36




            No, the first argument to select is the number of sockets you have in your fd_sets, but it is ignored in Winsock2 as @Yastanub said.
            – Ted Lyngmo
            Nov 19 at 15:36












            @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
            – Smit Ycyken
            Nov 19 at 15:50




            @TedLyngmo, it needed to keep support for Unix Berkeley sockets.
            – Smit Ycyken
            Nov 19 at 15:50


















             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377566%2fhow-to-get-rid-of-warning-c4244-c4267-conversion%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Tonle Sap (See)

            I get strange results when I access the Sqlitedatabase with Unity C# via XAMPP

            Guatemaltekische Davis-Cup-Mannschaft