[Bug 1941] New: Whither RTEMS_offsetof?

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1941

           Summary: Whither RTEMS_offsetof?
           Product: RTEMS
           Version: HEAD
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: cpukit
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: ralf.corsepius at rtems.org


The RTEMS_offsetof macro in 
cpukit/score/include/rtems/system.h
is potentially producing bogus results.

The rationale is given in Linux's "man offsetof":

<cite>
 This  macro is useful because the sizes of the fields that compose a structure
can vary across implementations, and compilers may insert different numbers of
padding bytes between fields.  Consequently, an ele‐
       ment's offset is not necessarily given by the sum of the sizes of the
previous elements.

       A compiler error will result if member is not aligned to a byte boundary
(i.e., it is a bit field).
</cite>


rtems-gcc's > 4.6 toolchains implement "offsetof" as a define to
__builtin_offsetof in stddef.h. Older ones implement it as a macro which is
more or less identical to RTEMS_offsetof (And thus also subject to this
potential defect.).


IMO, RTEMS_offsetof should
* either be entirely removed (and use-cases be replaced by "offsetof") 
or 
* the macro's content changed to using "offsetof" instead of explicit and
potentially broken address arithmetics.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.