triple-sigh. I am retesting to be sure. On Thu, May 30, 2013 at 6:29 AM, Eric Covener <cove...@gmail.com> wrote: > Our errors on > > On Thu, May 30, 2013 at 5:32 AM, Joe Orton <jor...@redhat.com> wrote: >> On Sun, May 05, 2013 at 03:12:20PM -0400, Eric Covener wrote: >>> On Sun, May 5, 2013 at 11:51 AM, Eric Covener <cove...@gmail.com> wrote: >>> > I've got an issue AIX where the test added prior to >>> > >>> > http://svn.apache.org/viewvc?view=revision&revision=1309386 >>> > >>> > Works before r1309386 but not after (EINVAL). Will look further this >>> > evening >>> >>> It seems like AIX, Solaris, HP, and Apple are in the byte/char camp >>> >>> Linux says integer. >>> >>> (This is strictly for the IPv4 flavors) >>> >>> Mladen -- do you recall if the 4 byte change for ipv4 was needed and where? >> >> I'm pretty sure this change was specifically to fix the IPv6 case and >> the effect on the v4 code was unintended. >> >> I checked the Linux kernel, it accepts a char or an int for the v4 >> options: http://lxr.linux.no/#linux+v3.9.4/net/ipv4/ip_sockglue.c#L454 >> >> The glibc header actually says char: >> >> #define IP_MULTICAST_TTL 33 /* u_char; set/get IP multicast ttl */ >> #define IP_MULTICAST_LOOP 34 /* i_char; set/get IP multicast loopback */ >> >> Stevens UNPv1 says using an int here is a "common programming error", >> and the transition to int with IPv6 options will be "less error >> prone"... maybe "differently error prone"? :) >> >> Does r1487796 (et al) work OK for you guys? > > Mine are failing on IPV6. I was a bit confused earlier on.
-- Eric Covener cove...@gmail.com
