> the very first one is impossible because of a validating guard[1]: `address_in_network` only gets called after `is_valid_cidr`, which enforces the presence of a slash.

It’s correct to flag this code. The check is performed manually outside of the function in question. If you call the function directly, the bug surfaces.

There is no mention in the function documentation of the validation requirement, making it easy to call incorrectly. Also, if it is required to call the validator before calling this function, then the function could just call it itself.

In short, it’s possible to make this code safe by definition, but instead it relies upon the developer to always make the undocumented right choices every single time it is called. I would expect something more rigorous from verified code.

> I would expect something more rigorous from verified code.

I think you just want the illusion of safety :p

A big advantage of verified code is that it enables you to write the sketchy and dangerous-looking code BECAUSE it's proven correct

In fact, skipping as many safety checks as possible is highly desirable. For performance, yes, but also because it's less code to maintain.

Our tools already do this to some extent, for performance. E.g. compilers that remove your bounds or type checks in the generated code when it can prove it's not needed.

That doesn't mean there's a problem with the code, only with the documentation. So the article is wrong to call it a "real bug". At most it's poor code style that could theoretically lead to a bug in the future.

There's nothing inherently wrong with a function throwing an exception when it receives invalid input. The math.sqrt function isn't buggy because it fails if you pass it a negative argument.