... if we cannot extend them.
On Tue, Mar 22, 2016 at 10:03 PM, William A Rowe Jr <[email protected]> wrote:
>
> If devs want to promote an API and then continuously break ABI on trunk,
> I'm way beyond arguing with such individuals. Just a few choice examples
> which had necessitated major MMN bumps that did not receive one...
>
> http://svn.apache.org/viewvc?view=revision&revision=1560081
> http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
> bitwise-alignment assurance)
> http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
> bitwise-alignment assurance)
These for sure broke users depending on bit alignement of the
bitfield(s), but isn't that really an abuse of the/any API?
Anyway, if we can't extend bitfields, we'd better not use them, and
favor plain (unsigned) integer types with #defined (or enum) bits
positions like:
#define req_set (APR_UINT64_C(1) << 0)
#define viaopt_set (APR_UINT64_C(1) << 1)
#define recv_buffer_size_set (APR_UINT64_C(1) << 2)
#define io_buffer_size_set (APR_UINT64_C(1) << 3)
#define maxfwd_set (APR_UINT64_C(1) << 4)
#define timeout_set (APR_UINT64_C(1) << 5)
#define badopt_set (APR_UINT64_C(1) << 6)
#define proxy_status_set (APR_UINT64_C(1) << 7)
#define source_address_set (APR_UINT64_C(1) << 8)
#define bgrowth_set (APR_UINT64_C(1) << 9)
#define bal_persist (APR_UINT64_C(1) << 10)
#define inherit (APR_UINT64_C(1) << 11)
#define inherit_set (APR_UINT64_C(1) << 12)
#define ppinherit (APR_UINT64_C(1) << 13)
#define ppinherit_set (APR_UINT64_C(1) << 14)
struct {
....
apr_uint64_t flags;
} proxy_server_conf;
We can then use them with (e.g.):
if (sconf->flags & ppinherit_set) {
....
}
That (at least) won't cause any breakage if we add a new flag or a
following (trailing) flags2.
My 2 cts...
