[ovs-dev] [ext-244 3/4] Remove assumption that there are 64 or fewer fields.

[Jarno Rajahalme]

On Jul 26, 2014, at 10:58 AM, Ben Pfaff <blp at nicira.com> wrote:

> On Sat, Jul 26, 2014 at 10:41:34AM -0700, Jarno Rajahalme wrote:
>>> On Jul 26, 2014, at 10:37 AM, Ben Pfaff <blp at nicira.com> wrote:
>>> On Sat, Jul 26, 2014 at 08:47:56AM -0700, Jarno Rajahalme wrote:
>>>>> -    enum ofputil_protocol usable_protocols_bitwise;
>>>>> +    uint32_t usable_protocols_bitwise;
>>>> 
>>>> These seem unrelated changes?
>>> 
>>> This is actually a sticky point.  Before this commit, meta-flow.h
>>> includes ofp-util.h, to get "enum ofputil_protocol" for these two
>>> members.  After this commit, ofp-util.h includes meta-flow.h, to get
>>> struct mf_bitmap.  The circular dependency causes a problem.  The best
>>> solution I came up with was to change the "enum ofputil_protocol"
>>> members to uint32_t.  It's not a great solution.  Do you have a good
>>> idea?
>> 
>> Can the enum be forward declared here instead?
> 
> Standard C doesn't have incomplete enums.  GNU C has them as an
> extension, but they are not useful.  From the GCC manual:
> 
>    5.42 Incomplete `enum' Types
>    ============================
> 
>    You can define an `enum' tag without specifying its possible values.
>    This results in an incomplete type, much like what you get if you write
>    `struct foo' without describing the elements.  A later declaration
>    which does specify the possible values completes the type.
> 
>     You can't allocate variables or storage using the type while it is
>    incomplete.  However, you can work with pointers to that type.
> 
>     This extension may not be very useful, but it makes the handling of
>    `enum' more consistent with the way `struct' and `union' are handled.
> 
>     This extension is not supported by GNU C++.


Moving the definition of the enum to a third header file could be an option, but I think your compromise is a good one as well, especially if you add a comment near the supported protocols members explaining the relation to the enum.

  Jarno