Re: [BUGS] Breakage with VACUUM ANALYSE + partitions - Mailing list pgsql-hackers

Hello Tom,

>> I understood the point and I do not see real disadvantages. The C standard
>> really says that an enum is an int, and compilers just do that.
>
> No, it doesn't say that, and compilers don't just do that.
> A compiler is specifically allowed to store an enum in char or short if 
> the enum's declared values would all fit into that width.

Hmm. That is a bit of a subtle one:

Spec says that enum *constants* are ints "The identifiers in an enumerator 
list are declared as constants that have type int and may appear wherever 
such are permitted."  But indeed, as you point out, per spec the storage 
could be made smaller.

However, I'm yet to meet a compiler which does not do ints:
  typedef enum { false, true } boolean;  assert(sizeof(boolean) == sizeof(int)); // ok with gcc & clang

I can guess why: such a compiler would not be able to work with libraries 
compiled with gcc or clang, which would be an pretty annoying feature. Now 
it does not mean that such a compiler does not exist in some realm (8/16 
bits architectures maybe? but then ints would be 16 bits on these...).

> (Admittedly, if you're choosing the values as powers of 2, an OR of them 
> would still fit;

Yep.

> but if you think "oh, an enum is just an int", you will get burned.)

In theory, yes. In practice, the compiler writer would have get burned 
before me:-).

> * compiler warnings if you forget some members of the enum in a switch

Sure. Using a switch on a bitfield is an uncommon pattern, though.

> * debugger ability to print variables symbolically

Yep.

Names are lost by defines, which is my preliminary concern to try to avoid 
them, even at the price of beting against the spec letter:-)

> At that point you might as well use the #defines rather than playing
> language lawyer about whether what you're doing meets the letter of
> the spec.

Hmmm... the compilers are the real judges, the spec is just the law:-)

> I note that C99 specifically mentions this as something a compiler might 
> warn about: [...]

Indeed. Neither gcc nor clang emit such warnings... but they might some 
day, which would be a blow for my suggestion!

Another option would have been explicit bitfields, something like:
  typedef struct {    int create : 1,        return_null : 1,        fail : 1,        create_in_recovery : 1,        //
...       ;  } extension_bitfield_t;
 
  void foo(extension_bitfield_t behavior)  {    if (behavior.create) printf("create...\n");    if
(behavior.return_null)printf("null...\n");    if (behavior.fail) printf("fail...\n");    if
(behavior.create_in_recovery)printf("recovery...\n");  }
 
  void bla(void)  {    foo((extension_bitfield_t) { .fail = 1, .create_in_recovery = 1 });  }

With gdb it is quite readable:
  // (gdb) p behavior  // $1 = {create = 0, return_null = 0, fail = -1, create_in_recovery = -1}

Anyway, thanks for the discussion!

-- 
Fabien.