Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 May 2019 08:19:55 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 237940] struct nvme_health_information_page{} @ /usr/include/dev/nvme/nvme.h has alignment issues.
Message-ID:  <bug-237940-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237940

            Bug ID: 237940
           Summary: struct nvme_health_information_page{} @
                    /usr/include/dev/nvme/nvme.h has alignment issues.
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: root+FreeBSD@linuxpedia.pl

struct nvme_health_information_page {

        uint8_t                 critical_warning;
        uint16_t                temperature;
        uint8_t                 available_spare;
/* ... */
} __packed __aligned(4);

has issues with alignment: `temperature` field can't be properly aligned on=
 any
current architecture which seems to defeat the `__aligned(4)` hint.

What has bitten me today is that it confuses some code-generating tools, li=
ke
Rust's bindgen. I already filed a bug to them, as they treat __packed
__aligned(4) as __packed(4) - which has a *totally* different meaning -  bu=
t it
would be nice to have some BSD compiler guru took a glimpse at this particu=
lar
structure and shed some light on whether __aligned(4) is OK here.=20

And yes, I know this structure layout is not BSD's idea =C2=AF\_(=E3=83=84)=
_/=C2=AF

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237940-227>