Re: [PATCHv3 1/6] Add missing includes and forward declares

[Elijah Newren <newren@gmail.com>]

On Tue, Aug 14, 2018 at 11:51 PM Elijah Newren <newren@gmail.com> wrote:
> > [...]
> > >> enums are of unknown size, so forward declarations don't work for
> > >> them.  See bb/pedantic for some examples.
> > >
> > > structs are also of unknown size; the size is irrelevant when the
> > > function signature merely uses a pointer to the struct or enum.  The
> > > enum forward declaration fixes a compilation bug.
> >
> > My rationale may miss the point but the standard and some real compilers
> > don't like this, unfortunately.
> >
> > For structs, having an incomplete type is fine, but for enums we need
> > the full definition.  E.g. C99 sayeth (in section 6.7.2.3 "tags")
> >
> >         A type specifier of the form
> >
> >                 enum identifier
> >
> >         without an enumerator list shall only appear after the type it
> >         specifies is complete.
>
> What about a type specifier of the form
>   enum identifier *
> ?  Can that kind of type specifier appear before the full definition
> of the enum?  (Or, alternatively, if the standard doesn't say, are
> there any compilers that have a problem with that?)
>
> If so, we can include cache.h instead.  We'll probably also have to
> fix up packfile.h for the exact same issue (even the same enum name)
> if that's the case.

Digging a little further this morning, apparently C++ has defined a
forward declaration of an enum to either be useless (because it was
already defined), require an explicit size specifier, or be a
compilation error.

That seemed stupid to me, but a little more digging turned up
http://c-faq.com/null/machexamp.html , which states that sizeof(char*)
!= sizeof(int*) on some platforms.  That was a big surprise to me.
Since an enum could be a char or int (or long or...), knowing the size
of the enum thus is important to knowing the size of a pointer to an
enum, so we actually do need the full enum definition (or a C++ style
explicit size specifier).

What a crazy world.

So, I'll go with the inclusion of cache.h and also fix up packfile.h
the same way.  Thanks for pointing this out, Jonathan.