Re: Optimizing memory footprint of bidi code

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:

Eli> I see a bidi_dir_t enumeration that has only 3 possible values.  Can
Eli> we trust modern compilers to use the smallest integer type for
Eli> enumerations?  If so, this part is already taken care of.  If not, how
Eli> to make this type smaller without losing the benefits of an enumerated
Eli> type (I don't want to manipulate magic values or macros)?

In C an enum is always an int.  In a struct the compiler will not
automatically shrink this to a bitfield.

However, you can declare it as a bitfield.  GCC will check to make sure
that all the enumeration values fit in the bitfield, so you will get an
error if you add a constant to the enum causing it to no longer fit.
Bitfield enums are not portable.  So, gcc and gdb do this:

#if defined(__GNUC__) && (__GNUC__ >= 2)
#define ENUM_BITFIELD(TYPE) enum TYPE
#else
#define ENUM_BITFIELD(TYPE) unsigned int
#endif

Then in the definition:

struct main_type
{
  ...
  ENUM_BITFIELD(type_code) code : 8;
  ...
};

I think this approach results in a good tradeoff of type safety, size,
and portability, as long as a significant fraction of developers are
using GCC.

Eli> Maybe manipulating bitfields is no longer an issue with current
Eli> architectures and compiler technology.

It increases code size, which can matter.  The only way to know for sure
is to try it and profile.

I can't answer the rest of your questions.

Tom