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

structures

so lots of threads on this forum say you must not care about how the compiler puts things into structures with alignment and padding and stuff

then we look at example code with structures used to access registers like in cmsis

who is right and what is safe?

Parents
  • so lots of threads on this forum say you must not care about how the compiler puts things into structures with alignment and padding and stuff

    Your view is rather extreme. Yes, structures can have non-portable alignment, padding, endianness. But when portability is not an issue, you can use structures to your benefit. That's the case with CMSIS: the library targets a specific CPU family, it also uses non-standard compiler features to make it work (hence, it works with a limited set of compilers.)
    I believe structures are often used for MCU register definitions. Again, those are MCU-specific and probably use non-standard compiler extensions. No portability here either.
    So it's portability vs. compiler-specific features. It takes some experience to find the right balance.

Reply
  • so lots of threads on this forum say you must not care about how the compiler puts things into structures with alignment and padding and stuff

    Your view is rather extreme. Yes, structures can have non-portable alignment, padding, endianness. But when portability is not an issue, you can use structures to your benefit. That's the case with CMSIS: the library targets a specific CPU family, it also uses non-standard compiler features to make it work (hence, it works with a limited set of compilers.)
    I believe structures are often used for MCU register definitions. Again, those are MCU-specific and probably use non-standard compiler extensions. No portability here either.
    So it's portability vs. compiler-specific features. It takes some experience to find the right balance.

Children
No data