>>> 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

Reply via email to