On Tue, Jun 26, 2018 at 8:21 AM, Eric Covener <cove...@gmail.com> wrote:
> On Tue, Jun 26, 2018 at 9:02 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > > > On Tue, Jun 26, 2018 at 2:48 PM, Eric Covener <cove...@gmail.com> wrote: > > > On Tue, Jun 26, 2018 at 8:37 AM Yann Ylavic <ylavic....@gmail.com> > wrote: > > >> > > >> On Mon, Jun 25, 2018 at 10:49 PM, Eric Covener <cove...@gmail.com> > 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?