Hi, just wondering if use of uv_timeval64_t instead of strut timeval could generate portability issues.
I'm basically creating a uv_timeval64_t with both tv_sec and tv_usec set to 0, and passing it to openssl lib to fill it. However when the host is a Raspberry Pi 3B+ the filled values do not make any sense (they are extremely high, which means there is some kind of overflow). ------------------------------------------------ struct timeval dtlsTimeout; dtlsTimeout.tv_sec = 0; dtlsTimeout.tv_usec = 0; int64_t ret = DTLSv1_get_timeout(this->ssl, (void*)&dtlsTimeout); if (ret == 0) return true; uint64_t timeoutMs = (dtlsTimeout.tv_sec * static_cast<uint64_t>(1000)) + (dtlsTimeout.tv_usec / 1000); ------------------------------------------------- The computed timeoutMs is (sometimes) 428358563266560000 (ms), which is 100% crazy (it cannot be more than a few ms typically). So I think the OpenSSL DTLSv1_get_timeout() function is filling the struct wrongly. I assume I should not pass a uv_timeval64_t to OpenSSL when it expects a struct timeval, am I right? -- Iñaki Baz Castillo <i...@aliax.net> -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. To view this discussion on the web visit https://groups.google.com/d/msgid/libuv/CALiegfmKYstnffxibfgoPpjvpmNDTMGxC3kjq0-WYf0hn6gVUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
