On 29 April 2015 at 11:34, Francois Gouget fgouget@free.fr wrote:
This fixes compilation on FreeBSD.
The only other files that use UINT32_MAX are:
- The .yy.c files. These are generated and always do an ifndef+define.
- dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason.
- dlls/jscript/string.c which simply defines it.
- dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac OS X headers.
Maybe mshtml and jscript should use inttypes.h, or to the contrary, maybe ws2_32 should use the ifndef+define approach.
Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.
On Wed, 29 Apr 2015, Henri Verbeet wrote: [...]
Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.
The timeout receives a 64 bit value so using an unsigned int would not work. But using UINT_MAX plus the native limits.h can work.
static inline INT64 get_rcvsnd_timeo( int fd, BOOL is_recv) ... timeout = get_rcvsnd_timeo(fd, optname == WS_SO_RCVTIMEO); *(int *)optval = timeout <= UINT32_MAX ? timeout : UINT32_MAX;
On Wed, Apr 29, 2015 at 7:22 AM, Francois Gouget fgouget@free.fr wrote:
On Wed, 29 Apr 2015, Henri Verbeet wrote: [...]
Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.
The timeout receives a 64 bit value so using an unsigned int would not work. But using UINT_MAX plus the native limits.h can work.
Hi all, I don't really understand why this change was made, windows uses 4 byte to set and get the value. It's not possible to set a value higher than 0xffffffff, actually I don't even now if that value is valid, only tests can tell the truth. Unless this is a very specific broken application that uses the mysterious unixism hack from socket.c:
5295 } else if (optlen == sizeof(struct timeval)) { 5296 WARN("SO_SND/RCVTIMEO for %d bytes: assuming unixism\n", optlen);
Best wishes, Bruno
On 04/29/15 14:13, Bruno Jesus wrote:
Hi all, I don't really understand why this change was made, windows uses 4 byte to set and get the value. It's not possible to set a value higher than 0xffffffff
When setting the timeout, the value may be rounded. If it's rounded up from 0xffffffff, the value will not fit in 32-bit unsigned type. It's not theoretical, I've seen this happening.
Jacek
On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban jacek@codeweavers.com wrote:
When setting the timeout, the value may be rounded. If it's rounded up from 0xffffffff, the value will not fit in 32-bit unsigned type. It's not theoretical, I've seen this happening.
Hi, Jacek. Thanks for the reply, so why can't we take care of the overflow inside the helper function and still return an ULONG to callers?
On 04/29/15 15:50, Bruno Jesus wrote:
On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban jacek@codeweavers.com wrote:
When setting the timeout, the value may be rounded. If it's rounded up from 0xffffffff, the value will not fit in 32-bit unsigned type. It's not theoretical, I've seen this happening.
Hi, Jacek. Thanks for the reply, so why can't we take care of the overflow inside the helper function and still return an ULONG to callers?
Its callers accept different types. getsockopt uses unsigned type, so it may handle all values up to 0xffffffff. In case of sendto and recv_base, we need to pass it to poll, which accepts signed types. That's why I left handling overflows to callers.
Jacek
On 29 April 2015 at 12:22, Francois Gouget fgouget@free.fr wrote:
The timeout receives a 64 bit value so using an unsigned int would not work.
Do you mean for "timeout" or for the assignment to "optval"? The current code is pretty much just broken for negative values. Since it's a timeout I'm guessing those just aren't supposed to happen, but in that case get_rcvsnd_timeo() should return a UINT64, and the assignment to "optval" should use e.g. "*(unsigned int *)optval = ...;".