Hacker News Reader

Comment by randomblock1 | Hacker News Reader

I thought most people used the explicit version:

  for (size_t i = count; i > 0; --i) {
      // use array[i - 1]
  }

You can also do something like:

  size_t index = i - 1;

to not have to use i-1. I believe the compiler optimizes that out anyway to be identical.

View on HN

I agree that more explicit is almost always better in C. It’s difficult enough as is :D

I would do it exactly like you suggest, but using an explicitly sized type like uint32_t instead.

If I write firmware or low-level code, I almost exclusively use integers with explicit bitwidth.

Yes, this is the best answer. This also works with `-fsanitize=unsigned-integer-overflow`.

Unsigned integer overflow is well defined, though. Not something that should be sanitized. A lot of code out there relies on it.

Ubsan is a misnomer here from a technical perspective. However overflow unsigned or not is unexpected in many cases. As such, sanitizing it (and many other hard to reason about behaviors) by default is great practice. For an example, when unsigned values are used to count, overflows from summing over 2**N often result in incorrect behavior. This may be incrementing or even counting beans.

One particularly famous example of a bug: https://projectzero.google/2023/01/exploiting-null-dereferen...

We usually get away with ignoring unsigned rollover because most application counts don't exceed 2**32 or 2**64. However, many can exceed these values, and in those cases, explicitly handling this case in critical systems is often better than ignoring potentially erroneous behavior.

Another concern, some people might have about this is the performance implications or what to do when you want to allow overflow. In that case you can locally disable overflow protections.

Reply on news.ycombinator.com