[Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member

[Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member

[joe.harvell at netscout dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93910

joe.harvell at netscout dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joe.harvell at netscout dot 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 inconsistency
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 different
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 type.
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 converted to
a pointer to the q-qualified
version of the type; the values stored in the original and converted pointers
shall compare equal.

3) An integer constant expression with the value 0, or such an expression cast
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 pointer
to any object or function.

4) Conversion of a null pointer to another pointer type yields a null pointer
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 entity
of the referenced
type, and might be a trap representation.[68])

6) Any pointer type may be converted to an integer type. Except as previously
specified, the result
is implementation-defined. If the result cannot be represented in the integer
type, the behavior is
undefined. The result need not be in the range of values of any integer type.

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 behavior 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), integer
types capable of
holding object pointers (7.20.1.4), simple assignment (6.5.16.1).

Endnotes:
[67] The macro NULL is defined in <stddef.h> (and other headers) as a null
pointer constant; see 7.19.

[68] The mapping functions for converting a pointer to an integer or an integer
to a pointer are intended
to be consistent with the addressing structure of the execution environment.

[69] In general, the concept “correctly aligned” is transitive: 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.