Re: [PATCH] declarednull: rename DECLARED to NULL

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Wed, Jan 06, 2021 at 09:33:49 -0800:
> On Wed, Jan 6, 2021 at 8:02 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > Bart Schaefer wrote on Mon, 04 Jan 2021 21:57 +00:00:
> > > So the "bits that need to be named" are:
> > > 1) the bit representing "remember that this was declared but no value
> > > was assigned"
> > > 2) the combination of that with PM_UNSET that represents "functionally
> > > behaves like NULL"
> >
> > To be clear, (2) would generally be used as testing whether _either_
> > PM_UNSET or the bit from #1 is set, right?
> 
> Most often it's used for changing the value of both bits at once, not
> testing.  The bits are almost always tested independently.

*nod*

> > How about, for #1, PM_BEEN_ASSIGNED or PM_INITIALIZED?
> 
> The latter was already rejected.  Both of these arguably describe the
> opposite of the actual state, that is, PM_HAS_NOT_BEEN_ASSIGNED would
> be more accurate ... but Felipe has essentially argued that after
> "unset foo" the variable still has not been assigned, so why clear a
> bit with that name?

After «unset», PM_UNSET would be set, and I don't immediately see why bit #1
should be tested at all if if PM_UNSET is set.  If the «unset» is followed by
an assignment and/or (re-)declaration, the value of bit #1 can then be set
properly, and PM_UNSET cleared.  Makes sense?

> PM_DECLARED_BUT_NEITHER_ASSIGNED_NOR_UNSET is just too verbose, and
> shortening it to just the first word got us into this discussion in
> the first place.
> 
> > As to the combination, my first inclination would have been to leave it
> > unnamed so that it's obvious PM_UNSET is being inspected, but if the
> > combination merits being named, then perhaps PM_HAS_VALUE(pm).
> 
> The reason for doing it the way I did is because (I presumed) most
> cases would never examine bit #1 because they are already examining
> PM_UNSET by itself.
> 
> PM_HAS_VALUE(pm) is actually also backwards.  It would usually be
> PM_HAS_NO_VALUE(pm).  But there's actually exactly one such test.

So long as we don't have «!PM_HAS_NO_VALUE(pm)» ☺