All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Forward declaration of enum iterator_selection?
Date: Mon, 8 Aug 2016 18:30:53 +0200	[thread overview]
Message-ID: <57A8B3BD.1000002@kdbg.org> (raw)
In-Reply-To: <0604cf0a-2b94-93b3-3a01-213ea5b9849b@ramsayjones.plus.com>

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


  reply	other threads:[~2016-08-08 16:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-05 22:26 Forward declaration of enum iterator_selection? Johannes Sixt
2016-08-07 20:34 ` Ramsay Jones
2016-08-08 16:30   ` Johannes Sixt [this message]
2016-08-08 18:28     ` Ramsay Jones
2016-08-08 18:52       ` Ramsay Jones
2016-08-10 22:46     ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57A8B3BD.1000002@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.