Message-ID: <7673A83E-DD1E-4E9B-A8D9-B68B315A5BE0@mit.edu>
From: Ken Raeburn <raeburn@MIT.EDU>
To: rt@krbdev.mit.edu
In-Reply-To: <rt-6308-29815.9.0077415021549@krbdev.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Subject: Re: [krbdev.mit.edu #6308] Alignment problem in resolver test
MIME-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 30 Dec 2008 13:43:12 -0500
References: <rt-6308-29815.9.0077415021549@krbdev.mit.edu>
RT-Send-Cc: 
Content-Length: 1684

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