| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the Java array allocation in InetAddress.cpp failed, we'd free NULL instead of the
previously-allocated structure. This is a new bug in froyo, but only happens in out of
memory situations, so doesn't seem worth fixing there.
Unrelatedly, let's disallow assignment and copying of all our RAII classes. This isn't
a mistake I've seen made, but it's easy to protect against, so we may as well do so
consistently.
Change-Id: I2433b31ff983d388788b09e59e08d661f1725ecd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old ioctl SIOCGIFCONF implementation of getNetworkInterfaces only returns
IPv4 addresses. Now we've switched everything over to IPv6, that's not good
enough. This change (a) implements glibc/BSD-like getifaddrs(3)/freeifaddrs(3)
for Android, and (b) rewrites our getNetworkInterfaces to use that method. Of
particular note is that we now do more of the work in Java. The JNI hands back
a Java equivalent of getifaddrs(3)'s linked list of ifaddrs structs. The new
package-private java.net.InterfaceAddress class serves as Java's "struct
ifaddrs".
The old implementation was also broken: SIOCGIFCONF doesn't actually return
interface indexes from the kernel as the old code believed, so we were
pulling the address family out of the IPv4 address it returned, leading
us to assign the index 2 to all network interfaces. This caused all kinds of
weird behavior later.
I also had to fix GenericIPMreq so that its interface index field is actually
set. The native code gets passed one of these objects when setNetworkInterface
is called, so it's kind of important that the object identify which interface
it's supposed to correspond to.
I've also added missing copyright headers.
This fixes all of the harmony tests on the simulator and on the device. It
fixes several but not all of the jtreg MulticastSocket and IPv6 tests.
|
|
|
A new LocalArray C++ class lets us specify a "reasonable" amount of stack to
use, but transparently fall back to using the heap if we need more space.
The three places I've chosen to use LocalArray in this patch are fairly
random; all they have in common is that they're the places where we call
GetStringUTFRegion. There are more places LocalArray will be useful: the
java.io.File JNI in particular.
Bug: 2257819
|
