Consider this code:

struct s
{
    int x;
    int y[sizeof((struct s*)0)->x];
};

The C23 has the following constraint (6.5.3.4p2):

The first operand of the -> operator shall have type "pointer to atomic, qualified, or unqualified structure" or "pointer to atomic, qualified, or unqualified union", and the second operand shall name a member of the type pointed to.

Here I don't see a requirement for such "pointer to atomic, qualified, or unqualified structure" to be pointer to atomic, qualified, or unqualified complete structure.

The example above seems to satisfy the constraint above. Why do major C compilers reject this code?

In this comment user Caleth thinks that "the lack of explicit requirement for -> to apply to complete types is an omission on the part of the C committee".

UPD. SDCC 4.5.0 accepts the code above.

Consider this code:

struct s
{
    int x;
    int y[sizeof((struct s*)0)->x];
};

The C23 has the following constraint (6.5.3.4p2):

The first operand of the -> operator shall have type "pointer to atomic, qualified, or unqualified structure" or "pointer to atomic, qualified, or unqualified union", and the second operand shall name a member of the type pointed to.

Here I don't see a requirement for such "pointer to atomic, qualified, or unqualified structure" to be pointer to atomic, qualified, or unqualified complete structure.

The example above seems to satisfy the constraint above. Why do major C compilers reject this code?

In this comment user Caleth thinks that "the lack of explicit requirement for -> to apply to complete types is an omission on the part of the C committee".

UPD. SDCC 4.5.0 accepts the code above.

• c
• pointers
• struct
• language-lawyer
• incomplete-type

• 3 Does an pointer to an incomplete type have any members that can be named? I don't see how to satisfy the second part of the requirement with an incomplete thing on the LHS. – Mat Commented 2 days ago
• @Mat: Per C 2024 6.2.1, the member name x is in scope where the example code in this question tries to use it: “Any other identifier has scope that begins just after the completion of its declarator.” – Eric Postpischil Commented 2 days ago
• 1 Interestingly (to me) the specs for the unary * operator also fail to require the operand to be a pointer to a complete type. Among other things, that means that it does not gain us any traction to argue that a->b is meant to be equivalent to (*a).b. – John Bollinger Commented 2 days ago
• 1 @JohnBollinger I noticed that some operators have the requirement of complete type indirectly, for example the prefix ++: "...and shall be a modifiable lvalue." Where the definition of modifiable lvalue in turn requires a complete type. – Lundin Commented yesterday
• @JohnBollinger Re: " the specs for the unary * operator also fail to require the operand to be a pointer to a complete type". It seems that the reason is to support &*x. Have a look at relevant questions (1, 2) and demo. – pmor Commented yesterday

1 Answer 1

I think it is correct to assume that this is a miss from the C committee.

For example with C11 the text "pointer to complete object type" was added to other postfix operator constraints like the [] operator. C99 didn't have that "complete" requirement. They didn't add a similar wording to -> and . for whatever the reason.

As noted in comments I don't really see how the second operand can name a member if the structure is incomplete though.