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.
