>>> At least this is what I normally use. The type of *option_value >>> might be platform dependent, but then we need some #ifdefs for >>> platforms. >> But the choice is still between 32- and 64-bit integers. And if so, >> you can distinguish among them at run time as accurately. Or should >> one say even > I'm not sure I understand what you are requesting. The implementation > of the IP_MTU defines the opt_value as an int.
Apparently I've carried away in the heat of discussion. You said option_value might be platform dependent and I assumed that some might want 32- and some might want 64-bit value. While this [some want 32, some 64] is true for option_len, all platforms seem to expect 32-bit for simple options. So that int declaration for option_val is sufficient [for now]. The comment therefore falls to "what *if*" category. I mean if you had ioctl that reports that it has written 4 or 8 bytes, then you could use that value to determine if it was 32- or 64-bit value returned and act accordingly. But never mind, once again, int declaration for option_val appears sufficient. > That code is platform specific. It is surrounded by #ifdef > OPENSSL_SYS_LINUX #endif We are looking in several platform specific > issues, like setting the TOS (for ECN) byte, setting the DF bit, > querying the interface MTU, receiving the ECN bits for DTLS. We will > provide one API, but the implementation is platform specific. It's hypothetical, but what if tomorrow it will become possible to reuse the code on another platform? All I'm saying is that it *might* prove to be useful to think outside Linux even within #idef LINUX. It's not a requirement, just wishful thinking... > So I > guess, we can fix this bug easily. However, according to initial > comment, all getsockopt() call are broken, right? This is a trick question. Does "initial" refer to Tomas's report about option_val or my comment about option_len? If former, see above, if latter, then yes, admittedly they are all effectively broken *in cases* when expected option_len is 64-bit value. There is a number of getsockopt calls in bss_dgram.c and there is one in b_sock.c. Most of them work out and don't break at run time, because 64-bit compilers usually allocate 64-bit slot even for 32-bit values on stack. It's *not* an excuse for not fixing them, merely an explanation for how it could have worked so far without causing trouble. On side note. Looking at first getsockopt in bss_dgram.c. In non-Windows case it passes pointer to timeval and says it's sizeof(int) large... How would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is initialized to 1? 'perror's are just wrong in context... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
