osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c


On Tue, Jun 26, 2018 at 8:21 AM, Eric Covener <covener@xxxxxxxxx> wrote:
On Tue, Jun 26, 2018 at 9:02 AM Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote:
>
> On Tue, Jun 26, 2018 at 2:48 PM, Eric Covener <covener@xxxxxxxxx> wrote:
> > On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <ylavic.dev@xxxxxxxxx> wrote:
> >>
> >> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <covener@xxxxxxxxx> wrote:
> >> >
> >> > Bill or Yann, do you remember the specific gotcha with setting aside
> >> > addl bits and re-using them later?
> >>
> >> I've never thought it was an issue (re compat) to add some bit(s) in a
> >> bitfield if there is a hole, wherever this field is in the struct.
> >> It doesn't change the size and there is no way for the user to have
> >> used the address of any bit in the first place (it can't break
> >> anything IMHO).
> >> Bill objected to this, I can't remember why (and he is in better
> >> position to explain it), status quo so far...
> >>
> >
> > Just to be clear, I am talking about claiming the lost ones _before_
> > the struct is further extended with a reserved :31 (or whatever) as
> > opposed to going back and claiming gaps from the past. Maybe the
> > former is OK.
>
> I think "reserved" or not doesn't change anything, name it or not the
> hole is there in any case.
> Why extending firstbit:1;reserved:31 to e.g.
> firstbit:1;secondbit:1;reserved:30 would be more compatible than the
> implicit firstbit:1;secondbit:1 ?
> Both should be allowed IMHO.

Speculating only, it seems like there is a gradient of risk:

 - Old unused bits we try to repurpose that someone is squatting on
 - New unused bits we try to claim now (this is the case for the
recent single bit field)
 - Unused bits that are explicitly marked as reserved when the first
bit field is defined.

My sole concern was whether the addition of c below...

struct {
  int a:2;
  int b:2;
  int c:2; /* Added */
}

...ever assured that the two bits of c will not displace a or b, and this
has never been a concern on Intel implementatins. Actually Eric you
have more background on big endian and odd word size architectures
than I do :) I've never found a reference that assures us of this, maybe
things have changed in very recent C specs?