This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

this is non portable code ?


unsigned char buf[100]
.
.
.
unsigned int val;
.
.
.
val = *((unsigned int *)(&buf[1]));
.
.
.

comments?

Parents
  • Misalignment detection not really up to the compiler. Some hardware -- the ARM7/9 core for example -- doesn't even detect alignment faults, and will just silently do interesting things to your byte lanes.

    There are some cases where compilers might be able to suspect or even prove alignnment problems, but I'm not sure that's possible in general, especially since actual positioning of the data is theoretically the job of the linker. Without inserting run-time checks on the actual value of a pointer just before it is used, which would have a huge effect on the code, I don't think a compiler can solve that problem in general. (Might make for an interesting debug option, just like an optional null pointer check that no compiler vendor offers as a debug option, either.)

    sorry about "multibyte word"

    Sounds good to me.

Reply
  • Misalignment detection not really up to the compiler. Some hardware -- the ARM7/9 core for example -- doesn't even detect alignment faults, and will just silently do interesting things to your byte lanes.

    There are some cases where compilers might be able to suspect or even prove alignnment problems, but I'm not sure that's possible in general, especially since actual positioning of the data is theoretically the job of the linker. Without inserting run-time checks on the actual value of a pointer just before it is used, which would have a huge effect on the code, I don't think a compiler can solve that problem in general. (Might make for an interesting debug option, just like an optional null pointer check that no compiler vendor offers as a debug option, either.)

    sorry about "multibyte word"

    Sounds good to me.

Children
No data