From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6DEB7385840B; Thu, 7 Oct 2021 16:41:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6DEB7385840B From: "joe.harvell at netscout dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member Date: Thu, 07 Oct 2021 16:41:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: joe.harvell at netscout dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 16:41:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93910 joe.harvell at netscout dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joe.harvell at netscout do= t com --- Comment #11 from joe.harvell at netscout dot com --- Stephane, This looks like a valid warning to me based on my reading of the standard (ISO/IEC 9899:2017) Programming Languages ---C). I'm looking at a draft version (N2176) of it. I understand you also complain about the inconsiste= ncy where warnings are not being emitted in similar cases. But I think it might help to see the basis for why the original warning for which you opened this bug report is valid. The code in question violates paragraph 7 from Section 6.3.2.3 Pointers: 7) A pointer to an object type may be converted to a pointer to a diffe= rent object type. If the resulting pointer is not correctly aligned [69]) for the referenced type, the behavior is undefined.... The entire section is excerpted below for context. 6.3.2.3 Pointers 1) A pointer to void may be converted to or from a pointer to any object ty= pe. A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer. 2) For any qualifier q, a pointer to a non-q-qualified type may be converte= d to a pointer to the q-qualified version of the type; the values stored in the original and converted pointe= rs shall compare equal. 3) An integer constant expression with the value 0, or such an expression c= ast to type void *, is called a null pointer constant.[67]) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a point= er to any object or function. 4) Conversion of a null pointer to another pointer type yields a null point= er of that type. Any two null pointers shall compare equal. 5) An integer may be converted to any pointer type. Except as previously specified, the result is imple- mentation-defined, might not be correctly aligned, might not point to an en= tity of the referenced type, and might be a trap representation.[68]) 6) Any pointer type may be converted to an integer type. Except as previous= ly specified, the result is implementation-defined. If the result cannot be represented in the integ= er type, the behavior is undefined. The result need not be in the range of values of any integer typ= e. 7) A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned [69]) for the referenced type, the behavio= r is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points = to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object. 8) A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the referenced type, the behavior is undefined. Forward references: cast operators (6.5.4), equality operators (6.5.9), int= eger types capable of holding object pointers (7.20.1.4), simple assignment (6.5.16.1). Endnotes: [67] The macro NULL is defined in (and other headers) as a null pointer constant; see 7.19. [68] The mapping functions for converting a pointer to an integer or an int= eger to a pointer are intended to be consistent with the addressing structure of the execution environment. [69] In general, the concept =E2=80=9Ccorrectly aligned=E2=80=9D is transit= ive: if a pointer to type A is correctly aligned for a pointer to type B, which in turn is correctly aligned for a pointer to type C, then a pointer to type A is correctly aligned for a pointer to type C.=