> On Jun 29, 2020, at 10:27 AM, Graham Leggett <minf...@sharp.fm> wrote: > > On 29 Jun 2020, at 14:49, Yann Ylavic <ylavic....@gmail.com > <mailto:ylavic....@gmail.com>> wrote: > >>> Yes we can and should (but in separate commits). >>> >>> I have my eye on the r->proxyreq flag, we can pack this into the binary >>> notes too, values don’t need to be one bit wide. >> >> Actually I was thinking the other way around, have the new "unsigned >> int strong_etag:1" bitfield rather than changing the existing ones... >> Why adding complexity with bit(s) macros while bitfields exist? > > The problem with bitfields in the public APIs is that they’re not binary > compatible across compilers. While it is very rare that a module will be > built with a different compiler than httpd was, it’s still theoretically > possible, and we should probably avoid it. Bitfields aren’t a problem for > in-module or in-core code.
++1
