12

While answer warning: assignment from incompatible pointer type for linklist array, I noticed any undeclared identifier perceded with struct keyword are considered as forward declared identifiers.

For instance the program below compiles well:

/* Compile with "gcc -std=c99 -W -Wall -O2 -pedantic %" */
#include <stdio.h>

struct foo 
{
    struct bar *next;  /* Linked list */
};


int main(void) {
    struct bar *a = 0;
    struct baz *b = 0;
    struct foo c = {0};

    printf("bar -> %p\n", (void *)a);
    printf("baz -> %p\n", (void *)b);
    printf("foo -> %p, %zu\n", (void *)&c, sizeof c); /* Remove %zu if compiling with -ansi flag */
    return 0;
}

My question: Which rule guides a C compiler to treat undeclared struct identifiers as forward declared incomplete struct types?

Community
  • 1
  • 1
Mohit Jain
  • 29,414
  • 8
  • 65
  • 93
  • I don't know but maybe because while in the midst of declaring `struct anything` you need to be able to use `struct anything`, and maybe the compiler won't handle all of that and simply treats it as existing? – Eregrith Jun 09 '15 at 07:46

4 Answers4

10

The Standard says (6.2.5.28)

All pointers to structure types shall have the same representation and alignment requirements as each other.

This means the compiler knows how to represent the pointers to any structure, even those that are (yet) undefined.
Your program deals only with pointers to such structures, so it's ok.

pmg
  • 98,431
  • 10
  • 118
  • 189
  • This sounds logical. Doesn't this make forward declarations useless. – Mohit Jain Jun 11 '15 at 09:18
  • In the particular case of using pointers to structures, yes. Declaring an incomplete structure before using a pointer to it is not necessary. – pmg Jun 11 '15 at 09:32
  • 1
    But creating a `typedef` to an incomplete type can be useful in allowing compiler type checking of arguments lists that follow using the typedef as opposed to simply passing void pointers. Good answer. – David C. Rankin Jun 11 '15 at 10:16
  • 1
    6.2.5.28 isn't terribly relevant. It is more a sort of rationale of "why it is supposed to work" but does not address anything about declarations (complete or incomplete) of structures. Thanks though for the link to the (draft) standard: it is better than the one I knew before. – Rhialto supports Monica Jun 16 '15 at 22:35
7

It is described in 6.2.5 Types and 6.7.2.3 Tags.

struct identifier is an object type.

6.2.5 Types

  1. The meaning of a value stored in an object or returned by a function is determined by the type of the expression used to access it. (An identifier declared to be an object is the simplest such expression; the type is specified in the declaration of the identifier.) Types are partitioned into object types (types that describe objects) and function types (types that describe functions). At various points within a translation unit an object type may be incomplete (lacking sufficient information to determine the size of objects of that type) or complete (having sufficient information). 37)

37) A type may be incomplete or complete throughout an entire translation unit, or it may change states at different points within a translation unit.

  1. An array type of unknown size is an incomplete type. It is completed, for an identifier of that type, by specifying the size in a later declaration (with internal or external linkage). A structure or union type of unknown content (as described in 6.7.2.3) is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope.

6.7.2.3 Tags

  1. All declarations of structure, union, or enumerated types that have the same scope and use the same tag declare the same type. Irrespective of whether there is a tag or what other declarations of the type are in the same translation unit, the type is incomplete 129) until immediately after the closing brace of the list defining the content, and complete thereafter.

129) An incomplete type may only by used when the size of an object of that type is not needed. It is not needed, for example, when a typedef name is declared to be a specifier for a structure or union, or when a pointer to or a function returning a structure or union is being declared. (See incomplete types in 6.2.5.) The specification has to be complete before such a function is called or defined.

2501
  • 24,549
  • 4
  • 42
  • 83
6

In addition to the answer provided by 2501, and your comment to it that "In my case, there is not even the forward declaration", the following.

Any use of a struct tag counts as a (forward) declaration of the structure type, if it had not been declared before. Although a more formal way would be to say that this simply counts as a type, since the C standard does not mention "forward declarations of structure types", just complete and incomplete structure types (6.2.5p22).

6.7.2 Type specifiers tells us that a struct-or-union-specifier is a type-specifier, and 6.7.2.1 Structure and union specifiers paragraph 1 tells us that that in turn struct identifier is a struct-or-union-specifier.

Suppose you have a linked list declaration, something like

struct node {
    struct node *next;
    int element;
};

then the "implicit forward declaration" of this incomplete type is essential for this structure to work. After all, the type struct node is only complete at the terminating semicolon. But you need to refer to it in order to declare the next pointer.

Also, a struct node declaration (of incomplete type) can go out of scope, just like any other declaration. This happens for instance if you have some prototype

int function(struct unknown *parameter);

where the struct unknown goes out of scope immediately at the end of the declaration. Any further declared struct unknowns are then not the same as this one. That is implied in the text of 6.2.5p22:

A structure or union type of unknown content (as described in 6.7.2.3) is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope.

That is why gcc warns about this:

foo.c:1:21: warning: 'struct unknown' declared inside parameter list
foo.c:1:21: warning: its scope is only this definition or declaration, which is probably not what you want

You can fix this by putting an extra forward declaration before it, which makes the scope start earlier (and therefore end later):

struct unknown;
int function(struct unknown *parameter);
2

I think that the most elegant use-case where incomplete struct types are used is something like this :

struct foo 
{
    struct bar *left;
    struct bar *right;
};
struct bar
{
    int something;
    struct foo *next;
};

I.e. double recursion, where a points to b and b points to a. Such cases might be a reason why this feature was included in original C language specification.

Original question is whether all struct identifiers are automatically forward declared. I think that it would be better to say that all incomplete struct definitions are automatically considered as forward declaration.

Edit: Following the comment about documentation, let's look at the C language bible : Kerninghan&Ritchie - The C Programming Language, section "6.5 Self-referential Structures" says :

Occasionally, one needs a variation of self-referential structures: two structures that refer to each other. The way to handle this is:

struct t {
    ...
    struct s *p;   /* p points to an s */
};
struct s {
    ...
    struct t *q;   /* q points to a t */
};

I agree, that it is possible to implement another way, but I would take this as good motivation from authors of the C language and I agree with them that it is elegant way to implement this.

ludvik02
  • 31
  • 5
  • Thanks for the answer. You can achieve the functionality very well with a forward declaration of `struct bar` above `struct foo`, so this can not be counted as real motivation. Apart from motivation to automatically forward declare, I am looking where is it documented in specs. – Mohit Jain Jun 17 '15 at 09:18
  • Thanks. I can see this on P115 in my version, although authors chose not elaborate this, but yeah, it appears the contents are deliberate and no details are skipped. – Mohit Jain Jun 17 '15 at 19:12