Either I found and fixed a severe bug in PSOCK_READTO() or I misunderstood something completely. To me PSOCK_READTO() is supposed to return if either the supplied character was read or if the user supplied buffer is exhausted - sor far so good.
However if the latter occurs up to now PSOCK_READTO() was continuing to process characters already read from the network (aka present in the uIP buffer) in order to check if the supplied character was found there and adjust the return value accordingly. But this means that the character processed this way were lost forever for the caller as the next call to PSOCK_READTO() would continue to read past the characters processed this way.
Therefore I removed that character processing altogether. So now if the user supplied buffer is exhausted before the supplied character is found the next call to PSOCK_READTO() starts exactly where previous call left off.
While it may very well be beneficial to have explict uiplib_ip4addrconv() and uiplib_ip6addrconv() available for IPv6 builds I'm having a hard time to see the point in uiplib_ip6addrconv() for IPv4 builds.
Unrelated to the above the dispatching of uiplib_ipaddrconv() to either uiplib_ip4addrconv() or uiplib_ip6addrconv() can be accomplished by the C preprocessor only thus avoiding the size/speed overhead of an additional callframe.
Better match user expectations by allowing to download plain disk images and configure the IP settings afterwards on the target machine - then most likely leveraging DHCP. This works for the users with the most usual Ethernet adapter and settings - which are now pre-configured in default.cfg's. Only the few users with non-default Ethernet adapter and/or settings are required to download a custom contiki.cfg and inject it manually into their disk image files.
There is a bug in the current route purge routine which would
result in a route's lifetime getting decremented more than once
during the same pass. This commit fixes it
The bug is documented here:
http://thread.gmane.org/gmane.os.contiki.devel/16209
