Re: OR_AND semantics (was: GNU property saga)

[Cary Coutant <ccoutant@gmail.com>]

> > I was trying to understand why HJ didn't care about case (b) -- if a
> > feature is used by at least one object, what difference does it make
> > whether we have some objects that didn't say whether they used the
> > feature? I believe his answer is that the use case for these
> > properties is to allow the OS to decide whether it can allocate a
> > program to a downgraded processor, based on whether we know for sure
> > that the program does *not* use a particular feature. Thus, case (c)
> > is the important one where the downgrade is feasible, and all other
> > cases mean that it is not (either because we know the feature is used,
> > or because we do not know it's not used).
>
> That might be, but truth be told, I'm more comfortable with an orthogonal
> design that can express more than we need right now, than with a design
> where two concepts (known and used) are merged in a non-natural way.

Agreed.

> HJ: what's your issue with the KNOWN+USED approach?  I would envision an
> encoding where e.g. even IDs encode the 32 KNOWN bits, and odd IDs encode
> the 32 USED bits.  Optionally we could retain the differentiation between
> OR vs. AND for the logical combination of the USED bits (where the KNOWN
> bits are always ANDed), though I'm not sure I would see the point for
> this.

There are other properties that need AND: ones where the OS depends on
the program supporting something, like IBT and SHSTK, rather than the
program depending on a feature supported by OS or CPU. So they
wouldn't always be paired as KNOWN/USED, there would also be some AND
properties standing on their own. In addition, if we want NEEDED
features in addition to USED features, they could form a triplet:
KNOWN/USED/NEEDED. Still, I think using the even/odd bit as an
indication whether we need to OR or AND is reasonable (kind of like
how we use that bit to indicate what kind of tag is used for DT
entries). If we can eliminate the need for the OR_AND beast, I think
we could assert that the only combining methods we need are OR and
AND.

(I went back and looked at one of HJ's early proposals for properties,
and the even/odd bit is the approach he originally took.)

> I really have stomach aches with the current design of the properties.

As you can tell from my posts on this topic, I agree strongly enough
to have tilted at this windmill far longer than I normally would have.
Thanks for chiming in!

-cary