Re: Ensuring that all the fields of struct predicate are initialized

On 5/14/24 11:15 PM, James Youngman wrote:
> One of the worries in the back of my mind with findutils has always been
> about whether all the fields in `struct predicate` actually get initialised
> correctly by the parser functions.

> However, perhaps there's another way to help us be confident that the
> implementation initialises everything in all code paths and is consistent.
>   Any ideas, folks?

Besides stronger usage of tools like -fanalyzer, I'd like to mention
that such uninitialized values would come from complexity, i.e., when
one simply forgets to set a proper default for - currently allegedly
unrelated fields.
Regarding that, I have still on the list to remove the cost-based optimizer
which leads to several wrong sorting results for the options.
A low-hanging fruit is the removal of the "est_success_rate".

Furthermore, I see some complexity due to the variety of utility functions
around predicates which already exist:
get_new_pred_chk_op, get_new_pred_noarg, insert_primary_withpred,
insert_primary, collect_arg_nonconst, ...
I would see some potential to make the code better readable.
Compared to other find(1) implementations, the GNU code is really
complex.

Re. the 'need*' fields: I also see some potential in using more "lazy"
determination of the values, i.e., eventually determine some values
later.

After all, such kind of changes bear quite some risk to introduce
new bugs ... at a time when the tool is quite stable.

For now, I'd rather consider only removing "est_success_rate" and do
the 4.10 release.  And then to plan further (depending on the availability
which recently was pretty small).

Featurewise, I see the following (which often has been discussed already):
- adding acl/xattr support
- improving birthtime support by changing to statx().

Have a nice day,
Berny