> One minor glitch is that there is an ad-hoc vadvise() call in
> advise() that is not tied to any particular entry in the
> advise_setting[] table.
I agree that we should use a separate "advice_setting" structure for this.
> I think we'd need to give a name to the advice_setting struct type,
> instanciate an ad-hoc instance on stack, and pass it down the callchain.
I agree. However, "advise()" originally passed "0" for
"display_instructions",
while "advise_if_enabled()" passed the negation of "level". With the new
interface,
we need a non-zero value for the ad-hoc setting to suppress the
instructions.
Using "ADVICE_LEVEL_ENABLED" or "ADVICE_LEVEL_DISABLED" would be a hack.
I suggest adding a dedicated "ADVICE_LEVEL_UNKNOWN" value to "enum
advice_level" for this case.