{"thread":{"id":"43021","subject":"Forward declaration of enum iterator_selection?","startedAt":"2016-08-06T20:42:56Z","lastAt":"2016-08-10T22:47:05Z","messageCount":6,"participants":["Johannes Sixt","Ramsay Jones","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293297","messageId":"933f540f-7752-cfce-5785-b67728fea987@kdbg.org","threadId":"43021","inReplyTo":null,"subject":"Forward declaration of enum iterator_selection?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-08-05T22:26:03Z","receivedAt":"2016-08-06T20:42:56Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"When refs.c is being compiled, the only mention of enum \niterator_selection is in this piece of code pulled in from \nrefs-internal.h (have a look at the preprocessed code):\n\ntypedef enum iterator_selection ref_iterator_select_fn(\n\t\tstruct ref_iterator *iter0, struct ref_iterator *iter1,\n\t\tvoid *cb_data);\n\nThis looks like a forward declarations of an enumeration type name, \nsomething that I thought is illegal in C. Am I wrong? (That may well be \nthe case, my C-foo is quite rusty.)\n\nMy compiler does not complain (it's gcc 4.8), but I thought I mention it \nbefore someone with a pickier compiler stumbles over it...\n\n-- Hannes\n"},{"id":"293326","messageId":"0604cf0a-2b94-93b3-3a01-213ea5b9849b@ramsayjones.plus.com","threadId":"43021","inReplyTo":"933f540f-7752-cfce-5785-b67728fea987@kdbg.org","subject":"Re: Forward declaration of enum iterator_selection?","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-08-07T20:34:12Z","receivedAt":"2016-08-07T20:34:37Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 05/08/16 23:26, Johannes Sixt wrote:\n> 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):\n> \n> typedef enum iterator_selection ref_iterator_select_fn(\n>         struct ref_iterator *iter0, struct ref_iterator *iter1,\n>         void *cb_data);\n> \n> 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.)\n\nAt this point 'enum iterator_selection' is an incomplete type and may\nbe used when the size of the object is not required. It is not needed,\nfor example, when a typedef name is being declared as a pointer to, or\nas a function returning such a type. However, such a type must be\ncomplete before such a function is called or defined.\n\n> 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...\n\nSo, I think this is correct.\n\nHaving said that, I would rather the 'enum iterator_selection' be defined\nbefore this declaration. One solution could be to #include \"iterator.h\"\nprior to _all_ #include \"refs/refs-internal.h\" in all compilation units\n(Note it is in the opposite order in refs/iterator.c). Alternatively, you\ncould put the #include \"../iterator.h\" into refs/refs-internal.h directly\n(some people would object to this).\n\nATB,\nRamsay Jones\n\n"},{"id":"293363","messageId":"57A8B3BD.1000002@kdbg.org","threadId":"43021","inReplyTo":"0604cf0a-2b94-93b3-3a01-213ea5b9849b@ramsayjones.plus.com","subject":"Re: Forward declaration of enum iterator_selection?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-08-08T16:30:53Z","receivedAt":"2016-08-08T16:31:07Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 07.08.2016 um 22:34 schrieb Ramsay Jones:\n> On 05/08/16 23:26, Johannes Sixt wrote:\n>> When refs.c is being compiled, the only mention of enum\n>> iterator_selection is in this piece of code pulled in from\n>> refs-internal.h(have a look at the preprocessed code):\n>>\n>> typedef enum iterator_selection ref_iterator_select_fn(\n>>          struct ref_iterator *iter0, struct ref_iterator *iter1,\n>>          void *cb_data);\n>>\n>> This looks like a forward declarations of an enumeration type name,\n>> something that I thought is illegal in C. Am I wrong? (That may well be\n>> the case, my C-foo is quite rusty.)\n>\n> At this point 'enum iterator_selection' is an incomplete type and may\n> be used when the size of the object is not required. It is not needed,\n> for example, when a typedef name is being declared as a pointer to, or\n> as a function returning such a type. However, such a type must be\n> complete before such a function is called or defined.\n\nAll you say is true when it is a struct type, of course. But I doubt that \nthere exists such a thing called \"incomplete enumeration type\" in C. In \nfact, with these keywords I found \nhttps://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html which indicates \nthat this is a GCC extension.\n\n> [...] I would rather the 'enum iterator_selection' be defined\n> before this declaration. One solution could be to #include \"iterator.h\"\n> prior to _all_ #include \"refs/refs-internal.h\" in all compilation units\n> (Note it is in the opposite order in refs/iterator.c). Alternatively, you\n> could put the #include \"../iterator.h\" into refs/refs-internal.h directly\n> (some people would object to this).\n\nI concur. Which one is the correct way to do, I do not know, either. It's \na matter how the interface is intended to be used. Perhaps the typedef \nmust be moved to iterator.h?\n\n-- Hannes\n\n"},{"id":"293379","messageId":"c1ef8a65-844f-b676-cae0-abba87930063@ramsayjones.plus.com","threadId":"43021","inReplyTo":"57A8B3BD.1000002@kdbg.org","subject":"Re: Forward declaration of enum iterator_selection?","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-08-08T18:28:54Z","receivedAt":"2016-08-08T18:29:16Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 08/08/16 17:30, Johannes Sixt wrote:\n> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:\n>> On 05/08/16 23:26, Johannes Sixt wrote:\n[snip]\n>> At this point 'enum iterator_selection' is an incomplete type and may\n>> be used when the size of the object is not required. It is not needed,\n>> for example, when a typedef name is being declared as a pointer to, or\n>> as a function returning such a type. However, such a type must be\n>> complete before such a function is called or defined.\n> \n> 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.\n\nAh, well spotted!\n\nYou prompted me to look at the C99 (and C11) standards, in particular\nsections 6.7.2.2 (Enumeration specifiers) and 6.7.2.3 (Tags).\n\nSo, while (technically) enumeration types are incomplete prior to the\nclosing } in its definition, the constraint imposed in 6.7.2.3-2 states:\n\n\t\"A type specifier of the form\n\t\tenum identifier\n\twithout an enumerator list shall only appear after\n\tthe type it specifies is complete\"\n\nwhich pretty much rules out its use here.\n\nATB,\nRamsay Jones\n\n"},{"id":"293380","messageId":"53ab8626-f862-a732-b369-abeab69a468f@ramsayjones.plus.com","threadId":"43021","inReplyTo":"c1ef8a65-844f-b676-cae0-abba87930063@ramsayjones.plus.com","subject":"Re: Forward declaration of enum iterator_selection?","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-08-08T18:52:05Z","receivedAt":"2016-08-08T18:52:13Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 08/08/16 19:28, Ramsay Jones wrote:\n> \n> \n> On 08/08/16 17:30, Johannes Sixt wrote:\n>> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:\n>>> On 05/08/16 23:26, Johannes Sixt wrote:\n> [snip]\n>>> At this point 'enum iterator_selection' is an incomplete type and may\n>>> be used when the size of the object is not required. It is not needed,\n>>> for example, when a typedef name is being declared as a pointer to, or\n>>> as a function returning such a type. However, such a type must be\n>>> complete before such a function is called or defined.\n>>\n>> 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.\n> \n> Ah, well spotted!\n> \n> You prompted me to look at the C99 (and C11) standards, in particular\n> sections 6.7.2.2 (Enumeration specifiers) and 6.7.2.3 (Tags).\n> \n> So, while (technically) enumeration types are incomplete prior to the\n> closing } in its definition, the constraint imposed in 6.7.2.3-2 states:\n> \n> \t\"A type specifier of the form\n> \t\tenum identifier\n> \twithout an enumerator list shall only appear after\n> \tthe type it specifies is complete\"\n> \n> which pretty much rules out its use here.\n\nBTW, you can make gcc be that 'pickier compiler' you mentioned, thus:\n\n$ rm refs.o\n$ make CFLAGS='-g -O2 -Wall -std=c99 -pedantic' refs.o\n    * new build flags\n    CC refs.o\nIn file included from refs.c:8:0:\nrefs/refs-internal.h:363:14: warning: ISO C forbids forward references to ‘enum’ types [-Wpedantic]\n typedef enum iterator_selection ref_iterator_select_fn(\n              ^\n$ \n\n:-D\n\nATB,\nRamsay Jones\n\n"},{"id":"293676","messageId":"a4f431a9-a758-a777-56c1-62bbe28f2072@alum.mit.edu","threadId":"43021","inReplyTo":"57A8B3BD.1000002@kdbg.org","subject":"Re: Forward declaration of enum iterator_selection?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-08-10T22:46:42Z","receivedAt":"2016-08-10T22:47:05Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/08/2016 06:30 PM, Johannes Sixt wrote:\n> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:\n>> [...] I would rather the 'enum iterator_selection' be defined\n>> before this declaration. One solution could be to #include \"iterator.h\"\n>> prior to _all_ #include \"refs/refs-internal.h\" in all compilation units\n>> (Note it is in the opposite order in refs/iterator.c). Alternatively, you\n>> could put the #include \"../iterator.h\" into refs/refs-internal.h directly\n>> (some people would object to this).\n> \n> I concur. Which one is the correct way to do, I do not know, either.\n> It's a matter how the interface is intended to be used. Perhaps the\n> typedef must be moved to iterator.h?\n\nThanks for noticing this problem.\n\nThe enum is meant to be available for the use of any iterator-type\nmodule, of which there are currently only ref-iterator and dir-iterator,\nand the latter doesn't happen to use this enum. I'd rather not move it\nto ref-internal.h because I think keeping it in a more public place will\nencourage people implementing other types of iterators to reuse it.\n\nMy understanding of the project policy is that it is OK for one header\nfile to include another header file iff the second header file is\nnecessary for the correct compilation of the first (but not only because\nusers of the first will usually want the second as well). So my\nsuggestion is to add an `#include \"iterator.h\"` to refs-internal.h.\n\nI also just realized that most \"*.[ch]\" files that live in\nsubdirectories use\n\n    #include \"foo.h\"\n\nto include header files from the main directory, but some (including\nrefs/files-backend.c) use\n\n    #include \"../foo.h\"\n\nI suspect that this inconsistency might cause problems for make and the\nautomatic dependency generation that it relies on, so the latter should\nprobably be changed to use the shorter pattern.\n\nMichael\n\n"}]}