LINUX.ORG.RU

История изменений

Исправление firkax, (текущая версия) :

Индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным. Проверять его просто так - не надо, да. А уязвимости не от этого, а от некомпетентных программистов, но их лучше к Си вообще не подпускать и давать им пхп-подобные языки, где даже после жёсткого бага в логике (а не какой-то там индекс) есть шанс продолжить работу относительно адекватно.

Зато на ламповых лаптях из 70-х не тормозит.

Опять ты за своё... Ты написал некую функцию и в общем случае не знаешь, как и сколько раз её будут вызывать в т.ч. через 50 лет. Где-то она сделает разницу в требованиях с 100мгц до 1000мгц, где-то - с 1 ядра 3ггц до 10 ядер 3ггц, а где-то - с 50 ядер до 500 ядер. Поэтому надо просто писать так, чтобы требования не раздувались. И тогда тебя не будет проклинать кто-то через десятки лет, когда какой-то незначительный компонент большой программы с твоим кодом внутри станет узким местом т.к. ты не знал что его будут вызывать миллион раз в секунду в каким-то сценарии использования.

Исправление firkax, :

Индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным. Проверять его просто так - не надо, да. А уязвимости не от этого, а от некомпетентных программистов, но их лучше к Си вообще не подпускать и давать им пхп-подобные языки, где даже после жёсткого бага в логике (а не какой-то там индекс) есть шанс продолжить работу относительно адекватно.

Зато на ламповых лаптях из 70-х не тормозит.

Опять ты за своё... Ты написал некую функцию и в общем случае не знаешь, как и сколько раз её будут вызывать в т.ч. через 50 лет. Где-то она сделает разницу в требованиях с 100мгц до 1000мгц, где-то - с 1 ядра 3ггц до 10 ядер 3ггц, а где-то - с 50 ядер до 500 ядер. Поэтому надо просто писать так, чтобы требования не раздувались. И тогда тебя не будет проклинать кто-то через десятки лет, когда из-за какой-то незначительный компонент большой программы с твоим кодом внутри станет узким местом.

Исправление firkax, :

Индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным. Проверять его просто так - не надо, да. А уязвимости не от этого, а от некомпетентных программистов, но их лучше к Си вообще не подпускать и давать им пхп-подобные языки, где даже после жёсткого бага в логике (а не какой-то там индекс) есть шанс продолжить работу относительно адекватно.

Зато на ламповых лаптях из 70-х не тормозит.

Опять ты за своё... Ты написал некую функцию и в общем случае не знаешь, как и сколько раз её будут вызывать в т.ч. через 50 лет. Где-то она сделает разницу в требованиях с 100мгц до 1000мгц, где-то - с 1 ядра 3ггц до 10 ядер 3ггц, а где-то - с 50 ядер до 500 ядер. Поэтому надо просто писать так, чтобы требования не раздувались.

Исправление firkax, :

Индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным. Проверять его просто так - не надо, да. А уязвимости не от этого, а от некомпетентных программистов, но их лучше к Си вообще не подпускать и давать им пхп-подобные языки, где даже после жёсткого бага в логике (а не какой-то там индекс) есть шанс продолжить работу относительно адекватно.

Зато на ламповых лаптях из 70-х не тормозит.

Опять ты за своё... Ты написал некую функцию и в общем случае не знаешь, как и сколько раз её будут вызывать. Где-то она сделает разницу в требованиях с 100мгц до 1000мгц, где-то - с 1 ядра 3ггц до 10 ядер 3ггц, а где-то - с 50 ядер до 500 ядер.

Исходная версия firkax, :

Индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным. Проверять его просто так - не надо, да. А уязвимости не от этого, а от некомпетентных программистов, но их лучше к Си вообще не подпускать и давать им пхп-подобные языки, где даже после жёсткого бага в логике (а не какой-то там индекс) есть шанс продолжить работу относительно адекватно.