If the caller didn't verify the plausibility of the parameters before calling the function, why is it safe to assume the caller will verify the plausibility of the function result?

Especially for embedded systems, I want the system to blow up on the developer's desk, not in the field, so I'd prefer to fail early.

Because the caller shouldn't know specifics on what is valid for the callee unless the caller has a specific and different value of valid. You don't leak information from separate functions this is how you get brittle garbage code.

> caller shouldn't know specifics on what is valid for the callee

Why? How do you even use an API if you don't know what you can pass into it?

For example strtol, you may pass whatever (implicitly nul terminated, which is bad) and it either returns a value or an error. I wasnt advocating _you_ don't know what to pass but that the caller doesn't include specifics of the callee.

There's a difference between handling all possible error cases (however unlikely) and handling impossible cases.

The moment you hit the latter case you can no longer make any assumptions about the state of the device and an abort/assert is an entirely appropriate thing to do.