Forward declaration of enum iterator_selection?

Forward declaration of enum iterator_selection?

[Johannes Sixt]

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

Re: Forward declaration of enum iterator_selection?

[Ramsay Jones]

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.

> 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

Re: Forward declaration of enum iterator_selection?

[Johannes Sixt]

Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
> 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.

> [...] 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

Re: Forward declaration of enum iterator_selection?

[Ramsay Jones]

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.

ATB,
Ramsay Jones

Re: Forward declaration of enum iterator_selection?

[Ramsay Jones]

On 08/08/16 19:28, Ramsay Jones wrote:
> 
> 
> 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

Re: Forward declaration of enum iterator_selection?

[Michael Haggerty]

On 08/08/2016 06:30 PM, Johannes Sixt wrote:
> 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