Re: [boost] overflow_traits

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2006-09-11 20:17:32

> From: Alexander Nasonov
> - Overflows tend to happen under rare circumstances and tests 
> usually don't cover all of them (or even don't cover at all)

You're right that the checks are not needed everywhere, but think of
places where a programmer *thought* they were not needed but in fact
they were - this is not so uncommon bug, and I treat this class as a
method to avoid such bugs. OTOH you seem to have a different goal - to
provide checks only when a programmer needs them. Maybe the best
solution, as Philippe Vaucher pointed out, is to have both interfaces
- one explicit (free functions), and the second - implicit (a wrapper
class, which would make use of the former).

> - Throwing an exception from a place where it's not expected 
> often breaks invariants (in C++, broken invariants are often 
> subtle and dangerous)

Not less than UB, which would probably happen in most situations where
the exception would be thrown. I think exception is way better than UB
;-)

> - No way to grep overflow checks

Good point.

> - I can hardly imagine that I change some int members of 
> popular classes in a hope that it would magically work when I 
> resolve hundreds of compiler erros

Oh, I think you exaggerate a bit ;-)

> >Also, I think the interface containing a bunch of C-style set of
> >functions with arguments' types pushed into the functions' names is
a
> >bit inadequate for a modern C++ library - it makes it very
difficult
> >to use your library in a generic code, and it makes it easy to
perform
> >unwanted argument conversions.
> 
> Don't say "generic" to people who care about security.

I don't see why genericity would make security to be sacrified... What
I was thinking of  was making the functions statically polymorphic,
and this would make them even more secure. This is because the user
doesn't have to care for the operands' type (which means less errors
when he makes a mistake as to what the type is). So, instead of

int addsi(int lhs, int rhs);
unsigned int addui(unsigned int lhs, unsigned int rhs);

there could be

  signed int add(  signed int,   signed int);
unsigned int add(unsigned int, unsigned int);

This way we have the same functionality the set of C-style functions
have, plus:
- there are no unintended implicit argument conversions when the user
makes error and uses a wrong function for a wrong type,
- if the type of the argument changes, there's no need to manually
change all the calls (which would be another error-prone activity),
- the functions can be used in generic code.
Is there really a reason why this approach is less secure than yours?

Best regards,
Robert