httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: About the relevance of bitfields usage (was: fate of mod_lbmethod_rr...)
Date Tue, 22 Mar 2016 21:50:23 GMT
I still can't find anything in the spec that suggests that extending these
is assured to maintain bitwise alignment.

That said, we can, provided we add an aligned break between them.  That
might mean introducing an interview flag, followed by a new series of
bitwise flags between, for example, the 2.4.20 and 2.4.21 releases.

Common sense tells me that alignment should be preserved, but unless we can
trust the spec to ensure that assumption, we should err on the side of
caution.
On Mar 22, 2016 4:46 PM, "Yann Ylavic" <ylavic.dev@gmail.com> wrote:

> ... if we cannot extend them.
>
> On Tue, Mar 22, 2016 at 10:03 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> 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...
>

Mime
View raw message