I.7: State postconditions - undefined behavior in first "consider using" about cppcoreguidelines HOT 8 OPEN

gcc also supports them:
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

from cppcoreguidelines.

While the stated issue is true, it is not the only one. Even I think that we can prove any software be failure under specific condition. The opposite is also true. In a way we can enter endless discussion. Hence we should constrain ourselves to given topic. The topic for which this example is "consider post condition". I guess this note is relevant for each point in this guide though. Best regards.

from cppcoreguidelines.

The text explicitly talks about checking for an overflow, though. Then I would expect the check to be valid C++ code:

We also left out the postcondition specification, so it is not obvious that the algorithm ( height * width ) is wrong for areas larger than the largest integer. Overflow can happen

from cppcoreguidelines.

You are right. The example could be improved in that sense. My point was just to underline the intention of the code, not its specific implementation.

from cppcoreguidelines.

Discussed on 11/30/2015.

from cppcoreguidelines.

Not all overflows are equal: integers used as indexes or buffer lengths are the ones you most care about as they affect memory or bounds safety.

There are cases where there are real issues--what should people write? It might make sense for the GSL to provide a mechanism to perform these operations that might overflow for signed integers. In the Guidelines we can direct people when to use these support functions.

The design issue is that if overflow is significant here, shouldn't it be an Expects rather than Ensures?

A safe_integer type may be desirable here--a type that you know has not overflowed. There are a few options out here--GDR, Neil, can you look at these? We should favor one that has a clean interface at the time being. Please also include a proposal as to whether this uses contracts internally and what level of control the user has over checking.

Decision: We'll have a discussion note about what to do about overflows and undefined behavior.

Thank you for raising this issue, @Kristine1975. We'll create a discussion section.

from cppcoreguidelines.

Regarding safe_integer library, I think this one is worth a look: http://doublewise.net/c++/bounded/ - I haven't used it in a big project though.

Regarding the checks: I think the typical way to check those things would look something like this:

Expects(height >= 0);
Expects(width >= 0);
Expects(height==0 || std::numeric_limits<int>::max() / height >= width);   
int res = height *  width;
Ensures(res>=0);     
return res;

In essence: you check the inverse operation with the maximal value a type can have. As you can see, it is quite a mouth full and hence I find it unlikely that it will get widespread use unless those checks are encapsulated in a type (and even then, the overhead might be forbidding in some cases).

from cppcoreguidelines.

We looked at this again today, but we've decided we need to postpone any action while we discuss Contracts in the C++ Standards Committee. This issue raises one of the most subtle points of Contracts.

from cppcoreguidelines.