On 3/14/25 13:34, Pierrick Bouvier wrote:
On 3/14/25 13:03, Richard Henderson wrote:
I'm not quite sure what you're arguing for here.
A build-time error is vastly preferable to a run-time error.
Even though this specific patch is safe (code calling those functions should be under
system anyway, so it should not be linked in a user binary), I just wonder if we should
not add explicit checks for this, for other kind of replacement we'll have to do.
Any such runtime check should not be for "system" vs "user", but for "feature
enabled".
If it's a lesser used configuration or feature, a run-time error could lay
dormant for
years before a user encounters it.
Sure, but wouldn't it better to have an explicit assert, instead of observing a random
behaviour?
What random behaviour are you suggesting?
I'm just worried we end up calling something we should not (user vs system, or any other
ifdef CONFIG/TARGET that might be hidden somewhere), and silently return a wrong value,
which would not be covered by our test suite.
Where is the wrong value going to be returned from, the stub?
Yes, many stubs do abort, typically after the "enabled" stub returns false.
It's still best if "feature enabled" is compile-time false when possible, such that
everything after the feature check gets compiled out. At which point we don't need the
stubs: they won't be reachable and errors are caught at build-time.
r~
