> The idea was to centralise the knowledge about what modes are valid
> rather than requiring every client to know the rules. From that point
> of view it seems inconsistent for the new interface to handle the
> bitregion_{start,end} restrictions (a correctness issue) but not the
> volatility restrictions (also a correctness issue). Especially when the
> interface already knows whether the field is volatile and already handles
> the choice between "narrow" and "wide" volatile bitfields.
Richard B.'s idea is precisely to reimplement -fstrict-volatile bitfields on
top of bitregion_{start,end}, that's why I'm not sure we want to make it part
of the interface at all.
--
Eric Botcazou
