3 ms·
>Assertions MUST NOT be the only thing between misbehavior and input data, including data returned from other APIs (e.g. fopen calls, i.e. auto x = fopen ("foo"
by 0xDEAFBEAD 3y ago
>Assertions MUST NOT be the only thing between misbehavior and input data, including data returned from other APIs (e.g. fopen calls, i.e. auto x = fopen ("foo"); assert (foo != NULL); is invalid). Anything dealing with foreign data must not assume anything about the state or contents of the data, and as such, cannot ever assert, as it doesn’t have an assertion to make. If you take away only one thing from this article, let it be this: assertions do not verify arbitrary inputs.
The author seems overconfident in this point. Like, what if the "input data" is from another software system I control?
Triggering an assert failure on bad user input is a little sloppy, but if there's no way to recover at that point anyways, I don't see why it matters.
Can someone enlighten me?
- brickers 3y agoRe: data from another of your own systems. If there’s an interface between them that suggests you probably want those systems decoupled. Maybe in the future you replace one system with another you don’t control - ideally it would be nice not to have to make code changes because of that. Re: asserting on user input. If you assert only then what happens on bad inputs when asserts are switched off in prod? Seems like an outcome you’d like to control at the time rather than allow to propagate (by writing bad data to a db and only being discovered months later, for example).
- 0xDEAFBEAD 3y ago>what happens on bad inputs when asserts are switched off in prod Good point