Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_dialup.c server/core.c server/util_etag.c

[Jim Jagielski <ji...@jaguNET.com>]

> On Jun 29, 2020, at 10:27 AM, Graham Leggett <mi...@sharp.fm> wrote:
> 
> On 29 Jun 2020, at 14:49, Yann Ylavic <ylavic.dev@gmail.com <ma...@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