459,676 Members | 1,253 Online
Need help? Post your question and get tips & solutions from a community of 459,676 IT Pros & Developers. It's quick & easy.

# Unaligned pointers question

 P: n/a Up until now, I was under the impression that when one talks about data alignment, what one means is at what address some data is stored. For instance, if we write unsigned int x ; assuming that sizeof(unsigned int) is 4 then &x will evaluate to some address the value of which will be a multiple of 4. The reasoning is analogous for the other fundamental data types supported by a given compiler. However, I recently came across the following: unsigned short * p = (unsigned short *) str ; where str has been defined as unsigned char * elsewhere, and points to some data. str can point to an address with an arbitrary value, as far as divisibility is concerned. unsigned short x ; unsigned short * y = &x ; *y = p[0] ; In my naivete, I thought that this last line would result in an unaligned access whenever the address p is not a multiple of 2 (assuming that sizeof(unsigned short) is 2) but my little test code shows that sometimes it does, sometimes it doesn't. Can anybody enlighten me here? What is the foolproof criterion to determine is some data is correctly aligned? Nov 15 '05 #1
7 Replies

 P: n/a On 2005-10-22, Steven Jones wrote: [...] However, I recently came across the following: unsigned short * p = (unsigned short *) str ; where str has been defined as unsigned char * elsewhere, and points to some data. str can point to an address with an arbitrary value, as far as divisibility is concerned. unsigned short x ; unsigned short * y = &x ; *y = p[0] ; In my naivete, I thought that this last line would result in an unaligned access whenever the address p is not a multiple of 2 (assuming that sizeof(unsigned short) is 2) but my little test code shows that sometimes it does, sometimes it doesn't. I have to ask HOW you determined whether that line resulted in an unaligned access or not. Your assertion that the divisibility of an address indicates the alignment is correct in practice (though the C standards do not guarantee that such a relationship between pointers and integers exists.) However, since unaligned access invokes undefined behavior in C, the implementation is free to behave in any way it chooses upon encountering such a construct, and that may be may be what you're seeing: Some processors require correct alignment for all types and yield a bus error for unaligned access, others do not (in particular, the x86 architecture can perform misaligned data access in exchange for a performance penalty), and still others may perform the access but silently yield unwanted results. Some operating systems work around such processor limitations by catching alignment faults and building your desired results from combining two aligned reads/writes, and some compilers can do the same thing in advance, such that the processor never gets to see the bad access. The fact that the access worked for you does not necessarily mean that the address is really correctly aligned. Nov 15 '05 #2

 P: n/a I hate following up to myself, but somebody's gotta do it ... On 2005-10-22, Nils Weller wrote: results from combining two aligned reads/writes, and some compilers can do the same thing in advance, such that the processor never gets to see the bad access. Actually compilers that try to prevent unaligned reads/writes in advance tend to do so by reading/writing the data byte-wise rather than in units of the particular type. -- Nils R. Weller, Bremen (Germany) My real email address is ``nilsgnulinuxnl'' .... but I'm not speaking for the Software Libre Foundation! Nov 15 '05 #3