threads / discuss / 43021

Forward declaration of enum iterator_selection?

Subject: Forward declaration of enum iterator_selection?

## tl;dr

6 messages between Aug 6, 2016 and Aug 10, 2016.

replies: 5people: 3as markdown or json

Johannes Sixt· Aug 5, 2016, 22:26 UTC · lore

When refs.c is being compiled, the only mention of enum iterator_selection is in this piece of code pulled in from refs-internal.h (have a look at the preprocessed code):

typedef enum iterator_selection ref_iterator_select_fn(
		struct ref_iterator *iter0, struct ref_iterator *iter1,
		void *cb_data);

This looks like a forward declarations of an enumeration type name, something that I thought is illegal in C. Am I wrong? (That may well be the case, my C-foo is quite rusty.)

My compiler does not complain (it's gcc 4.8), but I thought I mention it before someone with a pickier compiler stumbles over it...

-- Hannes
Ramsay Jones· Aug 7, 2016, 20:34 UTC · re: Johannes Sixt · lore

Re: Forward declaration of enum iterator_selection?

On 05/08/16 23:26, Johannes Sixt wrote:
Show 7 quoted lines
> When refs.c is being compiled, the only mention of enum iterator_selection is in this piece of code pulled in from refs-internal.h (have a look at the preprocessed code):
> 
> typedef enum iterator_selection ref_iterator_select_fn(
>         struct ref_iterator *iter0, struct ref_iterator *iter1,
>         void *cb_data);
> 
> This looks like a forward declarations of an enumeration type name, something that I thought is illegal in C. Am I wrong? (That may well be the case, my C-foo is quite rusty.)

At this point 'enum iterator_selection' is an incomplete type and may be used when the size of the object is not required. It is not needed, for example, when a typedef name is being declared as a pointer to, or as a function returning such a type. However, such a type must be complete before such a function is called or defined.

> My compiler does not complain (it's gcc 4.8), but I thought I mention it before someone with a pickier compiler stumbles over it...
So, I think this is correct.

Having said that, I would rather the 'enum iterator_selection' be defined before this declaration. One solution could be to #include "iterator.h" prior to _all_ #include "refs/refs-internal.h" in all compilation units (Note it is in the opposite order in refs/iterator.c). Alternatively, you could put the #include "../iterator.h" into refs/refs-internal.h directly (some people would object to this).

ATB, Ramsay Jones

Johannes Sixt· Aug 8, 2016, 16:30 UTC · re: Ramsay Jones · lore

Re: Forward declaration of enum iterator_selection?

Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
Show 18 quoted lines
> On 05/08/16 23:26, Johannes Sixt wrote:
>> When refs.c is being compiled, the only mention of enum
>> iterator_selection is in this piece of code pulled in from
>> refs-internal.h(have a look at the preprocessed code):
>>
>> typedef enum iterator_selection ref_iterator_select_fn(
>>          struct ref_iterator *iter0, struct ref_iterator *iter1,
>>          void *cb_data);
>>
>> This looks like a forward declarations of an enumeration type name,
>> something that I thought is illegal in C. Am I wrong? (That may well be
>> the case, my C-foo is quite rusty.)
>
> At this point 'enum iterator_selection' is an incomplete type and may
> be used when the size of the object is not required. It is not needed,
> for example, when a typedef name is being declared as a pointer to, or
> as a function returning such a type. However, such a type must be
> complete before such a function is called or defined.

All you say is true when it is a struct type, of course. But I doubt that there exists such a thing called "incomplete enumeration type" in C. In fact, with these keywords I found https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html which indicates that this is a GCC extension.

Show 6 quoted lines
> [...] I would rather the 'enum iterator_selection' be defined
> before this declaration. One solution could be to #include "iterator.h"
> prior to _all_ #include "refs/refs-internal.h" in all compilation units
> (Note it is in the opposite order in refs/iterator.c). Alternatively, you
> could put the #include "../iterator.h" into refs/refs-internal.h directly
> (some people would object to this).

I concur. Which one is the correct way to do, I do not know, either. It's a matter how the interface is intended to be used. Perhaps the typedef must be moved to iterator.h?

-- Hannes
Ramsay Jones· Aug 8, 2016, 18:28 UTC · re: Johannes Sixt · lore

Re: Forward declaration of enum iterator_selection?

On 08/08/16 17:30, Johannes Sixt wrote:
> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>> On 05/08/16 23:26, Johannes Sixt wrote:
[snip]
Show 7 quoted lines
>> At this point 'enum iterator_selection' is an incomplete type and may
>> be used when the size of the object is not required. It is not needed,
>> for example, when a typedef name is being declared as a pointer to, or
>> as a function returning such a type. However, such a type must be
>> complete before such a function is called or defined.
> 
> All you say is true when it is a struct type, of course. But I doubt that there exists such a thing called "incomplete enumeration type" in C. In fact, with these keywords I found https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html which indicates that this is a GCC extension.
Ah, well spotted!

You prompted me to look at the C99 (and C11) standards, in particular sections 6.7.2.2 (Enumeration specifiers) and 6.7.2.3 (Tags).

So, while (technically) enumeration types are incomplete prior to the closing } in its definition, the constraint imposed in 6.7.2.3-2 states:

	"A type specifier of the form
		enum identifier
	without an enumerator list shall only appear after
	the type it specifies is complete"
which pretty much rules out its use here.

ATB, Ramsay Jones

Ramsay Jones· Aug 8, 2016, 18:52 UTC · re: Ramsay Jones · lore

Re: Forward declaration of enum iterator_selection?

On 08/08/16 19:28, Ramsay Jones wrote:
Show 28 quoted lines
> 
> 
> On 08/08/16 17:30, Johannes Sixt wrote:
>> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>>> On 05/08/16 23:26, Johannes Sixt wrote:
> [snip]
>>> At this point 'enum iterator_selection' is an incomplete type and may
>>> be used when the size of the object is not required. It is not needed,
>>> for example, when a typedef name is being declared as a pointer to, or
>>> as a function returning such a type. However, such a type must be
>>> complete before such a function is called or defined.
>>
>> All you say is true when it is a struct type, of course. But I doubt that there exists such a thing called "incomplete enumeration type" in C. In fact, with these keywords I found https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html which indicates that this is a GCC extension.
> 
> Ah, well spotted!
> 
> You prompted me to look at the C99 (and C11) standards, in particular
> sections 6.7.2.2 (Enumeration specifiers) and 6.7.2.3 (Tags).
> 
> So, while (technically) enumeration types are incomplete prior to the
> closing } in its definition, the constraint imposed in 6.7.2.3-2 states:
> 
> 	"A type specifier of the form
> 		enum identifier
> 	without an enumerator list shall only appear after
> 	the type it specifies is complete"
> 
> which pretty much rules out its use here.
BTW, you can make gcc be that 'pickier compiler' you mentioned, thus:
$ rm refs.o
$ make CFLAGS='-g -O2 -Wall -std=c99 -pedantic' refs.o
    * new build flags
    CC refs.o
In file included from refs.c:8:0:
refs/refs-internal.h:363:14: warning: ISO C forbids forward references to ‘enum’ types [-Wpedantic]
 typedef enum iterator_selection ref_iterator_select_fn(
              ^
$ 
:-D

ATB, Ramsay Jones

Michael Haggerty· Aug 10, 2016, 22:46 UTC · re: Johannes Sixt · lore

Re: Forward declaration of enum iterator_selection?

On 08/08/2016 06:30 PM, Johannes Sixt wrote:
Show 11 quoted lines
> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>> [...] I would rather the 'enum iterator_selection' be defined
>> before this declaration. One solution could be to #include "iterator.h"
>> prior to _all_ #include "refs/refs-internal.h" in all compilation units
>> (Note it is in the opposite order in refs/iterator.c). Alternatively, you
>> could put the #include "../iterator.h" into refs/refs-internal.h directly
>> (some people would object to this).
> 
> I concur. Which one is the correct way to do, I do not know, either.
> It's a matter how the interface is intended to be used. Perhaps the
> typedef must be moved to iterator.h?
Thanks for noticing this problem.

The enum is meant to be available for the use of any iterator-type module, of which there are currently only ref-iterator and dir-iterator, and the latter doesn't happen to use this enum. I'd rather not move it to ref-internal.h because I think keeping it in a more public place will encourage people implementing other types of iterators to reuse it.

My understanding of the project policy is that it is OK for one header file to include another header file iff the second header file is necessary for the correct compilation of the first (but not only because users of the first will usually want the second as well). So my suggestion is to add an `#include "iterator.h"` to refs-internal.h.

I also just realized that most "*.[ch]" files that live in subdirectories use

    #include "foo.h"

to include header files from the main directory, but some (including refs/files-backend.c) use

    #include "../foo.h"

I suspect that this inconsistency might cause problems for make and the automatic dependency generation that it relies on, so the latter should probably be changed to use the shorter pattern.

Michael

← back to recent threads