Lpc2000

When you use an explicit cast, you are telling the compiler that you know 
what you are doing and the compiler should leave you alone, so that's what 
it did. For example, if you always ensure that the buf starts at an even 
address, and that you only do things like
         tmp = *(unsigned short *)&buf[i];
where i is even, then the warning would be unnecessary.

Bottom line - casts should not be used willy nilly without fully 
understanding what's happening.

At 01:17 PM 11/16/2005, Marko Panger wrote:

>Hello all,
>
>I have a general programming question. Me and my co-workers had an
>discussion about data alignment and non-aligned accesses. Please
>consider the following situation where an un-aligned access was made
>resulting in wrong value.
>
>char buf[5] = {1,2,3,4,5};
>
>unsigned short tmp;
>
>tmp = *(unsigned short*)&buf[1];       /* &buf[1] is on a odd address
>
>My co-workers expected that tmp will contain the value0x0203, but the
>value was 0x02. I understand that, because ARM7 core does not support
>un-aligned accesses and the compiler was forced to use a word access on
>a odd address. This code was ported from an 8-bit machine where it was,
>off course, working. My question is if all 32-bit devices would have the
>same problem with this code and why when we tested the same situation on
>a PC using Borland Builder compiler it was working as my co-workers
>expected. Is this a CPU(+cpu bus) issue or it is also compiler dependent.
>
>Although I thing this is bad programming practice and it calls for
>errors I am asking if it is possible to enable a warning for such
>situations.
>
>Regards,
>Marko
>
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)