Здравствуйте, vopl, Вы писали:

V>>Причем тут size_t и почему ты считаешь, что он "более уместен"? Результат вычитания двух указателей имеет тип ptrdiff_t. Можно легко представить платформу, где первый гораздо меньше второго.
V>size_t меньше ptrdiff_t? Вряд ли. Стандарт требует чтобы этот тип вмещал размер любого объекта, включая тот самый массив, разницу индексов которого вмещает ptrdiff_t. Таким образом, он гарантированно не меньше ptrdiff_t.

Пусть у нас 16-битная платформа (чтобы числа не были страшными) и адреса от 0 до 65535.
Для size_t достаточно 16 бит. Для ptrdiff_t, чтобы поддержать все значения от +65535 до -65535 — 17 бит.

Проблема общеизвестная, и её решают тем, что ни одному объекту не позволяют достигать в размере 1/2 адресного пространства (причём требование именно "меньше space/2", а не "не больше space/2"! потому что в дополнительном коде +32768 тоже не влезет). Но это значит, что для size_t достаточно на один бит меньше (15, а не 16). Ч.Т.Д.

(Реально на современных платформах общего пользования это обеспечивается тем, что половина адресного пространства занята ядром, а в остальном есть ещё код, стек и т.п.
Но на embedded запросто получить и более хитрые конфигурации, в которых проблема может вылезти в полный рост.)

V>Он "более уместен" потому что не имеет знака, который на самом деле не нужен. Из за этого, например, мой компилятор не генерирует дополнительную проверку на отрицательность в том цикле.

А с чего бы это быть той проверке? Есть масса других вариантов обойти.