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
