[krbdev.mit.edu #6308] Alignment problem in resolver test

[Ken Raeburn via RT]

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