Всем привет
при написании класса динамического массива озадачился проверкой на переполнение
решил посмотреть известные реализации взял файл garray.c из библиотеки GLIB
рассмотрим любую функцию оттуда например эту
так вот первое переполнение при сложении array->len + len и второе при умножении
elt_size * (i) так вот при использовании GArray можно получать уникальные состояния
например
len = 2147484036
alloc = 1024
тоесть размер занимаемой памяти намного меньше длинны массива абсурд
но при некоторых обстоятельствах запросто подобную фигню получить
вот я пишу сейчас тоже массив и думаю бросить так или проверять на переполнение
если проверять то это тормоза придется к __int64 кастить не хотелось бы этого
оставить так быть неуверенным в правильных результатах всегда
что думаете по этому поводу ?
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>что думаете по этому поводу ?
Для индексации и адресации используется тип вроде size_t, диапазон значений которого перекрывает максимально возможный размер массива, поэтому никто и не проверяет.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>что думаете по этому поводу ?
Кё>Для индексации и адресации используется тип вроде size_t, диапазон значений которого перекрывает максимально возможный размер массива, поэтому никто и не проверяет.
если использовать size_t да еще на 64 битной машине то и на переполнение
не провериш на 32 битной хоть можно к 64 битам откастить и посмотреть
проблема не в типе (как раз наоборот тип 32 битный специально выбран
как размер массива его можно и на 32 и на 64 кастингом проверить) а в том что приходится
складывать и умножать цифры которые потенциально могут приводить к переполнениям
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>если использовать size_t да еще на 64 битной машине то и на переполнение J>не провериш на 32 битной хоть можно к 64 битам откастить и посмотреть
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, Кодёнок, Вы писали:
Кё>>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>>что думаете по этому поводу ?
Кё>>Для индексации и адресации используется тип вроде size_t, диапазон значений которого перекрывает максимально возможный размер массива, поэтому никто и не проверяет. J>если использовать size_t да еще на 64 битной машине то и на переполнение J>не провериш на 32 битной хоть можно к 64 битам откастить и посмотреть J>проблема не в типе (как раз наоборот тип 32 битный специально выбран J>как размер массива его можно и на 32 и на 64 кастингом проверить) а в том что приходится J>складывать и умножать цифры которые потенциально могут приводить к переполнениям
Мне тоже интересен этот вопрос.
Понятно, что не обязательно иметь тип с удвоенной разрядностью. Можно делать что-то вроде такого:
unsigned int a = ...;
unsigned int b = ...;
...
unsigned int a_half = a / 2;
unsigned int b_half = b / 2;
unsigned int max_half = UINT_MAX / 2;
unsigned int AplusB = 0;
if ( a_half + b_half < max_half )
// a и b можно складывать
AplusB = a + b;
else// возможно переполнениеthrow ...;
BFE>Мне тоже интересен этот вопрос. BFE>Понятно, что не обязательно иметь тип с удвоенной разрядностью. Можно делать что-то вроде такого:
BFE>[ccode] BFE>unsigned int a = ...; BFE>unsigned int b = ...; BFE>... BFE>unsigned int a_half = a / 2; BFE>unsigned int b_half = b / 2; BFE>unsigned int max_half = UINT_MAX / 2;
BFE>unsigned int AplusB = 0;
BFE>А как правильно ?
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>Здравствуйте, Кодёнок, Вы писали:
Кё>>>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>>>что думаете по этому поводу ?
Кё>>>Для индексации и адресации используется тип вроде size_t, диапазон значений которого перекрывает максимально возможный размер массива, поэтому никто и не проверяет. J>>если использовать size_t да еще на 64 битной машине то и на переполнение J>>не провериш на 32 битной хоть можно к 64 битам откастить и посмотреть J>>проблема не в типе (как раз наоборот тип 32 битный специально выбран J>>как размер массива его можно и на 32 и на 64 кастингом проверить) а в том что приходится J>>складывать и умножать цифры которые потенциально могут приводить к переполнениям
BFE>Мне тоже интересен этот вопрос. BFE>Понятно, что не обязательно иметь тип с удвоенной разрядностью. Можно делать что-то вроде такого:
BFE>
BFE>unsigned int a = ...;
BFE>unsigned int b = ...;
BFE>...
BFE>unsigned int a_half = a / 2;
BFE>unsigned int b_half = b / 2;
BFE>unsigned int max_half = UINT_MAX / 2;
BFE>unsigned int AplusB = 0;
BFE>if ( a_half + b_half < max_half )
BFE> // a и b можно складывать
BFE> AplusB = a + b;
BFE>else
BFE> // возможно переполнение
BFE> throw ...;
BFE>
BFE>А как правильно ?
Ytz
а умножение ?
B0FEE664
пока вижу или юзать кастинг для проверки переполнения при умножении
или изменить алгоритм чтоб убрать умножение из него сейчас вот ковыряю STL
там кстати реализовано вычитанием и сравнением
вот кусок
тут есть функция _Distance которая считает сколько надо добавить элементов
внутри у нее это _Off += _Last — _First;
и вот что интересно если при вычитании а потом делении на размер типа может
распростринится знаковый бит вместо shr там sar в итоге дает неправильное
количество элементов для например такого кода
vector<short> v;
v.assign((short*)0x2,(short*)0x80000002);
то казалось бы он должен продсчитать 1073741824 элементов между этими адресами
а выдает _Off = 3221225472 следом валит проверку тут (max_size() — size() < _Count)
и выкидывает ассерт но по крайней мере уникальных состояний нет в STL алгоритме
наверное его и реализую у себя
интересно почему правильное количество элементов между указателями выполеяется только
если знаковый бит сброшен у результата который делится на размер типа вот что для этого кода сгенерено
short *_Last = 0x80000002, *_First = 0x2;
_Off += _Last - _First;
00414F72 8B 45 0C mov eax,dword ptr [_Last]
00414F75 2B 45 08 sub eax,dword ptr [_First]
00414F78 D1 F8 sar eax,1 ; вот тут если знаковй бит есть быть беде
00414F7A 8B 4D 10 mov ecx,dword ptr [_Off]
00414F7D 03 01 add eax,dword ptr [ecx]
00414F7F 8B 55 10 mov edx,dword ptr [_Off]
00414F82 89 02 mov dword ptr [edx],eax
Здравствуйте, Sir-G, Вы писали:
_>>При переполнении знакового целочисленного может быть UB. SG>Кстати где это в стандарте написано? И именно знакового?
Именно знакового — не знаю, но есть общий пункт (ANSI ISO IEC 14882 2003):
5.5
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable
values for its type, the behavior is undefined, unless such an expression is a constant expression
(5.19), in which case the program is ill-formed.
[Note: most existing implementations of C + + ignore integer
overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point
exceptions vary among machines, and is usually adjustable by a library function. ]
Здравствуйте, B0FEE664, Вы писали:
BFE>Именно знакового — не знаю, но есть общий пункт (ANSI ISO IEC 14882 2003):
3.9.1 Fundamental types
4 Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number
of bits in the value representation of that particular size of integer.41)
41) This implies that unsigned arithmetic does not overflow because a result that cannot be represented by the resulting unsigned integer
type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer
type.
BFE>Именно знакового — не знаю, но есть общий пункт (ANSI ISO IEC 14882 2003):
BFE>[q] BFE>5.5 BFE>If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable BFE>values for its type, the behavior is undefined,
беззнаковое переполнение всегда было well-defined, потому что оно определяется по модулю степени двойки.
Соответственно, твой пункт не применим, потому что результат попадает в range по определению
Q>>NB: верно только для беззнаковых типов
BFE>А разве здесь не undefined behavior в соответствии с пунктом 5.5 стандарта 2003-его года ?
Пункт 5.5 называется "5.5 Pointer-to-member operators". В данном случае применяется параграф 4 главы "3.9.1 Fundamental types":
Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2**n where n is the number
of bits in the value representation of that particular size of integer.
Здравствуйте, xor90h, Вы писали:
X>Здравствуйте, quodum, Вы писали:
Q>>При сложении элементарно:
Q>>
if ( a + b < a )
Q>>{
Q>> // overflow!
Q>>}
X>Скорее так:
X>
if ( a + b < MAX(a,b) )
X>{
X> // overflow!
X>}
X>Проверяется элементарно, для беззнаковых 8-ми битных интов: a = 3, b = 0xff. Ваш код переполнения не обнаружит.
3 + 0xff = 2 для беззнаковых 8-ми битных интов. Не?
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>вот я пишу сейчас тоже массив и думаю бросить так или проверять на переполнение J>если проверять то это тормоза придется к __int64 кастить не хотелось бы этого J>оставить так быть неуверенным в правильных результатах всегда J>что думаете по этому поводу ?
1. Задолго до переполнения кончится память
2. Можно и не кастить. Пусть c = a + b. Если произошло переполнение, то c будет меньше a и меньше b. Если переполнения не произошло, c будет больше или равен a и b. Верно для любого целочисленного типа, если арифметика двоичная и работает так, как она везде работает
При сложении двух беззнаковых 8-битных целых каждый операнд перед вычислением суммы будет преобразован к int (в представлении которого по стандарту должно быть не менее 16 бит), и результат вычисления суммы также будет иметь тип int. Естественно, при таком раскладе ни о каком переполнении не может быть и речи (пока результат явным образом не пытаются запихнуть в 8-битное целое, но это уже другой разговор).
я в итоге запилил как в STL правда все пропало с тех пор как умерла ось
и была переустановлена
например у меня была функция max_size() которая имела такой вид
size_ хранил текущее количество в итоге можно было безопасно умножать
после такой проверки ну и
size_t c = a + b;
assert(c >= std::min(a, b));
реально помогал в некоторых местах в итоге тогда получился реально
безопасный контейнер левые циферки не принимал на провоцирование
переполнения плевался ассертами а не тупо с ума сходил как GArray )
то что работал он только с примитивными типами это да ну я тогда от си фанател
и с цепепе только знакомился сейчас бы может что получше написал ...
Здравствуйте, Masterkent, Вы писали:
G>>3 + 0xff = 2 для беззнаковых 8-ми битных интов. Не?
M>При сложении двух беззнаковых 8-битных целых каждый операнд перед вычислением суммы будет преобразован к int (в представлении которого по стандарту должно быть не менее 16 бит), и результат вычисления суммы также будет иметь тип int. Естественно, при таком раскладе ни о каком переполнении не может быть и речи (пока результат явным образом не пытаются запихнуть в 8-битное целое, но это уже другой разговор).
Не совсем понятно почему "результат вычисления суммы также будет иметь тип int",
Ведь:
3.9.1.4 Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number
of bits in the value representation of that particular size of integer.
B0FEE664:
G>>>3 + 0xff = 2 для беззнаковых 8-ми битных интов. Не?
M>>При сложении двух беззнаковых 8-битных целых каждый операнд перед вычислением суммы будет преобразован к int (в представлении которого по стандарту должно быть не менее 16 бит), и результат вычисления суммы также будет иметь тип int. Естественно, при таком раскладе ни о каком переполнении не может быть и речи (пока результат явным образом не пытаются запихнуть в 8-битное целое, но это уже другой разговор).
BFE>Не совсем понятно почему "результат вычисления суммы также будет иметь тип int"
Clause 5 p.9:
Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:
— If either operand is of scoped enumeration type (7.2), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
— If either operand is of type long double, the other shall be converted to long double.
— Otherwise, if either operand is double, the other shall be converted to double.
— Otherwise, if either operand is float, the other shall be converted to float. — Otherwise, the integral promotions (4.5) shall be performed on both operands. [Footnote: As a consequence, operands of type bool, char16_t, char32_t, wchar_t, or an enumerated type are converted to some integral type.] Then the following rules shall be applied to the promoted operands:
— If both operands have the same type, no further conversion is needed.
[...]
5.7 Additive operators — p.1:
The additive operators + and — group left-to-right. The usual arithmetic conversions are performed for operands of arithmetic or enumeration type.
4.5 Integral promotions:
1 A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.
2 A prvalue of type char16_t, char32_t, or wchar_t (3.9.1) can be converted to a prvalue of the first of
the following types that can represent all the values of its underlying type: int, unsigned int, long int,
unsigned long int, long long int, or unsigned long long int. If none of the types in that list can
represent all the values of its underlying type, a prvalue of type char16_t, char32_t, or wchar_t can be
converted to a prvalue of its underlying type.
4.13 Integer conversion rank — p.1:
Every integer type has an integer conversion rank defined as follows:
— No two signed integer types other than char and signed char (if char is signed) shall have the same rank, even if they have the same representation. — The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller size.
— The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char. — The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
— The rank of any standard integer type shall be greater than the rank of any extended integer type with the same size.
— The rank of char shall equal the rank of signed char and unsigned char.
— The rank of bool shall be less than the rank of all other standard integer types.
— The ranks of char16_t, char32_t, and wchar_t shall equal the ranks of their underlying types (3.9.1).
— The rank of any extended signed integer type relative to another extended signed integer type with the same size is implementation-defined, but still subject to the other rules for determining the integer conversion rank.
— For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than T3, then T1 shall have greater rank than T3.
Из всего этого с учётом требований ко вместимости int следует, что о каких бы 8-битных целых ни шла речь, они при сложении (в том виде, как это было представлено выше) неизбежно будут "продвинуты" до int и результирующее значение также будет типа int.
Здравствуйте, Masterkent, Вы писали:
M>пока результат явным образом не пытаются запихнуть в 8-битное целое, но это уже другой разговор.
Верно ли, что гарантируется, что когда мы запихнем 3+255=258 типа int в 8-битный unsigned char, то все же получим 2?
Sir-G:
M>>пока результат явным образом не пытаются запихнуть в 8-битное целое, но это уже другой разговор. SG>Верно ли, что гарантируется, что когда мы запихнем 3+255=258 типа int в 8-битный unsigned char, то все же получим 2?
Да.
С++11 — 4.7 Integral conversions — p.2:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2ⁿ where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). —end note ]