On Dec 30, 2008, at 11:42, Jorgen Wahlsten via RT wrote: > For what it's worth, I think Sun's C compiler *always* aligns the > automatic > variables on 8-byte boundaries, while GCC tries to fit the > addrcopy[4] into > the "padding" of myname[256+1] (7 bytes padding?), as an > optimization. It > does seem strange that this is done *without* optimization though. I worked on GCC in a past job, so please forgive a brief diversion: It's not an optimization you'd turn on or off. The "optimization" is built into the code that decides how the stack frame is laid out. A char array doesn't need any special alignment, so myname[] doesn't have padding, it just ends, with the following byte probably at an odd address; since addrcopy[] is also a char array without special alignment needs, it's allowed to be put there. > Regardless, of the differences between Sun's C compiler and GCC, I > would be > inclined to agree with you that this is a solaris C library bug, > that is > being triggered by using GCC in this particular case. > > As for my comment about using an in_addr pointer, I think I merely > looked at > the EXAMPLE section in the solaris 2.10 gethostbyaddr man page. > There is > also a NOTE in that man page about INET_ADDR. The POSIX spec I just pulled up says the address argument points to an address, not a bunch of bytes, and in particular, > The addr argument of gethostbyaddr() shall be an in_addr structure > when type is AF_INET. (Presumably they meant the pointed-to thing.) So, converting it to an actual in_addr would probably be the right fix (though it leaves us with IPv6 support still missing in those places). Ken