Cppcoreguidelines: ES.104: Don't underflow is actually ES.103 Don't overflow in the sense of the language

[PeterSommerlad]

ES.104: Don't underflow

Reason

Decrementing a value beyond a minimum value can lead to memory corruption and undefined behavior

According to the language rules, what is described here is actually "overflow".

"underflow" has another distinct meaning.

Suggestion by ISO SC22 WG23 and WG21 SG12:

• Merge the example of ES.104 into ES.103
• Drop rule ES.104

[AndrewPardoe]

Per our editor's discussion, this question should be phrased as to whether there is a difference to the reader of the items. The guidance on each of these items is the same: to use unsigned types if you want modulo arithmetic. Should this be a separate item if the guidance is the same?

Also, you mention that there is another distinct meaning of "underflow". What is the meaning of "underflow" that you're referring to? How would the guidance (and enforcement clauses) be different if we explained this to the reader?

[xtofl]

Indeed "underflow" is defined only in the context of fractional arithmetic: the absolute value of a number becomes smaller than 'epsilon'. Cf. https://en.wikipedia.org/wiki/Arithmetic_underflow.

[PeterSommerlad]

I consider my original recommendation of dropping ES.104 still valid. Do I need to do anything else?

[hsutter]

@PeterSommerlad Yes, we are asking that you clarify your comment that

"underflow" has another distinct meaning.

so we know what meaning you have in mind. Then, the followup question is whether under that definition ES.104 would have different description/examples/guidance than ES.103.

[PeterSommerlad]

the comment by xtofl answered that already, IMHO, therefore, I didn't add anything else myself.

[masterl]

Yeah, this seems like a misunderstanding of "underflow" meaning by whoever has written ES.104.
As far as I know, overflow is when you go over the maximum that a variable can hold, be the value negative or postive, for example:

signed char c;

c = 129; // overflow (signed char can't store more than 128 value)
c = -128; // overflow (signed char can't store values lower than -127)

overflow <- | signed char value range (-127 <-> 128) | -> overflow

An underflow in this situation would be something like trying to store 0.5 on c, since it's lowest precision is a difference of 1 between each element.

---

Aside from that, the worse thing is that the example really have nothing to do with overflowing or not...

int a[10];
a[-2] = 7;   // bad

int n = 101;
while (n--)
    a[n - 1] = 9;   // bad (twice)

The example simply show an out-of-bounds array access error, it has nothing to do with overflowing...

It would be right if it were something like this:

float n = numeric_limits<float>::epsilon();
float m = n / 2;   // bad

[johnmcfarlane]

@masterl, I took a look at the confusion about these terms in Wikipedia and the observation about the confusing example in ES.104 is highly relevant. Buffer underflow seems to be the term for when an element at a too-low memory address is referenced. This is often the result of negative overflow. At least one Wikipedia citation arguing for the incorrect definition of integer underflow seems to conflate these two types of bugs.

What to do? I think that negative overflow should be mentioned by name in ES.103. Then perhaps we should either delete ES.104 entirely or replace it with a warning against integer precision loss, e.g.

auto a{3/2};  // 0, not 1.5. Possible counts as integer underflow(?)
auto b{3/4};  // 0, not .75. Definitely counts as integer underflow!

[hsutter]

@johnmcfarlane Thanks for pinging this thread back to life.

Clarifying Q: For the first one, you mean "1, not 1.5," right?

[johnmcfarlane]

@hsutter oops, yes:

auto a{3/2};  // 1, not 1.5. Possibly counts as integer underflow(?)
auto b{3/4};  // 0, not .75. Definitely counts as integer underflow!