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())
_______~~~~~~~~~______________________________________
c++ compiler-warnings winsock2
add a comment |
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())
_______~~~~~~~~~______________________________________
c++ compiler-warnings winsock2
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
add a comment |
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())
_______~~~~~~~~~______________________________________
c++ compiler-warnings winsock2
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
c++ compiler-warnings winsock2
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
add a comment |
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
add a comment |
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.
add a comment |
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
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+1supposed 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 toselectis the number of sockets you have in yourfd_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
|
show 4 more comments
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 19 at 16:25
answered Nov 19 at 16:19
Yastanub
475213
475213
add a comment |
add a comment |
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
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+1supposed 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 toselectis the number of sockets you have in yourfd_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
|
show 4 more comments
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
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+1supposed 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 toselectis the number of sockets you have in yourfd_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
|
show 4 more comments
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
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
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+1supposed 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 toselectis the number of sockets you have in yourfd_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
|
show 4 more comments
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+1supposed 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 toselectis the number of sockets you have in yourfd_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
|
show 4 more comments
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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