httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r1034916 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/proxy_util.c
Date Mon, 22 Nov 2010 13:08:47 GMT

On Nov 16, 2010, at 1:31 PM, William A. Rowe Jr. wrote:

> On 11/16/2010 8:29 AM, Graham Leggett wrote:
>> On 16 Nov 2010, at 2:35 AM, Nick Kew wrote:
>> 
>>> Well, you *could*.  You'd just (probably) sacrifice the optimisation.
>>> Much the same story as a bunch of chars.
>>> 
>>> FWIW, if I'd been designing the above from scratch, those flags
>>> would be a bitfield and a set of #defines, thus occupying a
>>> fixed/known width in the struct.  Compared to that, using :1
>>> just enables the compiler to optimise to an indeterminate size
>>> according to its alignment rules.
>> 
>> Given that v2.4 isn't baked right now, it looks like a very sensible suggestion to
change
>> it in this way.
>> 
>> At the very least, it gives us the option to add bit fields (to a sensible limit)
without
>> having to stick them on the end.
> 
> If we go this route, to introduce single bit flags, I'm still strongly opposed to
> int mbmr:1;  at the very least, lets use unsigned to avoid sign extension, please?
> 

++1...

However, I will quote Kernighan & Pike in "The Practice of Programming":

    "Don't use C or C++ bitfields; they are highly non-portable and tend
     to generate voluminous and inefficient code"

    "Languages have dark corners where practice varies - bitfields in
     C and C++ for example - and it is prudent to avoid them"

    "Bitfields are so machine-dependent that no one should use them"



Mime
View raw message