On Jun 11, 2012, at 10:47 AM, Andy Polyakov wrote: >>>> 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 option_value is different for different socket options. And if the socket option is not part of the "common" set of socket options, the type might be platform specific.... > 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. Yes, for know, as you say. > >> 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... Well, that socket option is currently only available on Linux. If it becomes available on other platforms, we have to re-consider the code in OpenSSL. Maybe the other platform really duplicates the function provided by Linux or does it differently. Then the #ifdefs can be adopted... > >> 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 Sorry for not being clear. I was referring to your comment regarding the final argument of getsockopt(), which *socklen_t, but you use specific code to deal with platforms which don't have that type in the accept() call. So I was asking if the same mechanism should also be used for all getsockopt() calls. > 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 That seems to be a bug. Robin: Can you submit a patch? > would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is > initialized to 1? 'perror's are just wrong in context... That seems to be another bug. Robin: Can you fix that, too?
Best regards Michael > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
