Bitfields in core_dir_config

[Sander Striker]

Hi,

Why are we using bitfields in core_dir_config?
Do we really care about a few bits?

Not to mention it is inconsistent:

    /* Hostname resolution etc */
#define HOSTNAME_LOOKUP_OFF     0
#define HOSTNAME_LOOKUP_ON      1
#define HOSTNAME_LOOKUP_DOUBLE  2
#define HOSTNAME_LOOKUP_UNSET   3
    unsigned int hostname_lookups : 4;

Here, we have a bitfield of 4 bits wide.  So,
range is 0-15.

    signed int do_rfc1413 : 2;   /* See if client is advertising a username? */

    signed int content_md5 : 2;  /* calculate Content-MD5? */

Why two bit wide flag fields (if one would do)?

#define USE_CANONICAL_NAME_OFF   (0)
#define USE_CANONICAL_NAME_ON    (1)
#define USE_CANONICAL_NAME_DNS   (2)
#define USE_CANONICAL_NAME_UNSET (3)
    unsigned use_canonical_name : 2;

Here we have a 2 bit wide bitfield, range is 0-3.
What's so different between hostname_lookups and
use_canonical_name?

Personally I would much rather see:

    /* Hostname resolution etc */
    enum {
        HOSTNAME_LOOKUP_OFF = 0,
        HOSTNAME_LOOKUP_ON,
        HOSTNAME_LOOKUP_DOUBLE,
        HOSTNAME_LOOKUP_UNSET
    } hostname_lookups;

    apr_bool_t do_rfc1413;   /* See if client is advertising a username? */

    apr_bool_t content_md5;  /* calculate Content-MD5? */

    enum {
        USE_CANONICAL_NAME_OFF = 0,
        USE_CANONICAL_NAME_ON,
        USE_CANONICAL_NAME_DNS,
        USE_CANONICAL_NAME_UNSET
    } use_canonical_name;

Ofcourse we would need to introduce apr_bool_t for that one
(apr just screams for a boolean type :).  But even if we don't,
is there any reason not to use enums instead of bitfields?

Sander