On Feb 12, 2016 2:24 AM, "Yann Ylavic" <[email protected]> wrote: > > On Fri, Feb 12, 2016 at 2:04 AM, <[email protected]> wrote: > > Author: wrowe > > Date: Fri Feb 12 01:04:58 2016 > > New Revision: 1729929 > >
> > + /** Originator's DNS name, if known. NULL if DNS hasn't been checked, > > + * "" if it has and no address was found. N.B. Only access this though > > + * ap_get_useragent_host() */ > > + char *useragent_host; > > const char * ? > Christophe has made some changes recently to add const to r->protocol > (trunk only, can't be backported...), I think we shoudn't introduce > new char* in "public" structs. While I would generally agree, the note states you must not access this member directly, so it seems irrelevant. But such a change should be harmless. > > + /** have we done double-reverse DNS? -1 yes/failure, 0 not yet, > > + * 1 yes/success > > + * TODO: 2 bit signed bitfield when this structure is compacted > > + */ > > + int double_reverse; > > }; > > I see this TODO about bitfield, but never seen it done in your > commits, so I wonder where Rainer's warning comes from... > Anyway, once backported (as you propose), we can hardly change it. Precisely, it will NOT change in 2.4 and should not change, and is only applicable to trunk. I should have omitted from the initial commit. If we define this as int :2 and add a second int :2, none of the c standards promise that the initial 2-bit value maintains its previous alignment. The alignment is undefined. When we refactor trunk structures in anticipation of 2.6/3.0, that will be the time to permanently park short bit values adjacent to one another. If backported, we should redact the comment. Cheers, Bill
