The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code in dgram_ctrl() is completely wrong -
>>
Actually similar argument applies even to sockopt_len. Modulo fact
that you get into trouble in cases when *expected*
sizeof(sockopt_len) is 8, while the value is declared int. The
situation is intensified by fact that in some cases expected
sizeof(sockopt_len) depends on compiler flags. And I'm not talking
about -m32 vs. -m64 compiler flags, I'm talking about flags in
64-bit case [Tru64 for one if you have to know]. One way to attack
the problem is depicted in crypto/bio/b_sock.c:975. I mean union
between unsigned int and size_t, explicit zeroing of size_t member
and heuristic that detects big-endian trouble. Then one can declare
even sockopt_val as similar union and pick int or long depending on
calculated sockopt_len being 4 or 8.
General comment:
Can't you use socklen_t as the type of the last argument?
As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't
have socklen_t. Of course one can question if these platforms are modern
enough/worth to care about, but why not, if it's feasible and enriching?
Or course one can go for #ifdef, but does one have to?
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 more accurately, because it's actual value, not assumed one from
compile time. Of course, absolute majority of compiled code heavily
relies on assumed values being equal to actual, but it's not prohibited
to assume that there are not, is it? #ifdefs have to be maintained in
sense that you have to follow their changes on multiple platforms, while
#ifdef-free alternative simply adapts to whichever situation with *no*
maintenance.
Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man
page says, that the type of the option_value is int. So I guess the
bug is simply, that the code uses long sockopt_val instead of int
sockopt_val. All this is specific to Linux.
Can you guarantee that the code in question won't ever become
interesting to reuse even in non-Linux context? I mean do you really
have to assume Linux that categorically? In other words in context of
multi-platform code such as OpenSSL there is value in *not* assuming things.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
