The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Анализ зависимости безопасности кода от используемого языка программирования, opennews (??), 20-Дек-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


24. "Анализ зависимости безопасности кода от используемого языка ..."  +1 +/–
Сообщение от Аноним (24), 20-Дек-20, 20:05 
Проблемы C++ от того, что его упорно смешивают с Си. Как правило указатели используется там, где без них можно обойтись и швыряют их через всю программу. Естественно, что надёжность в данном случае как у Си в котором почти всё отдаётся на откуп программисту.
Ответить | Правка | Наверх | Cообщить модератору

27. "Анализ зависимости безопасности кода от используемого языка ..."  –1 +/–
Сообщение от анонимуслинус (?), 20-Дек-20, 20:20 
> Проблемы C++ от того, что его упорно смешивают с Си. Как правило
> указатели используется там, где без них можно обойтись и швыряют их
> через всю программу. Естественно, что надёжность в данном случае как у
> Си в котором почти всё отдаётся на откуп программисту.

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Анализ зависимости безопасности кода от используемого языка ..."  –1 +/–
Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:15 
> он тем и хорош , что все под контроль программисту.

В C отнюдь не всё на деле "под контроль программисту". Это всего лишь довольно лживый (и успешный) пропагандистский лозунг, призванный заставить пользоваться C. А на деле - множество разных ситуаций потери контроля. Так в частности ни в C, ни в C++ так ничего за много лет и не сделано против полной потери контроля в случае хотя бы простого арифметического переполнения... Нет даже простого способа обнаружить такое переполнение. В C++ вводятся совершенно дурацкие вещи, но данная проблема не решается.

Ответить | Правка | Наверх | Cообщить модератору

78. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Аноним (24), 21-Дек-20, 03:39 
> хотя бы простого арифметического переполнения...

Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение. Есть вполне стандартные конструкции для проверки переполнения, которые для компилятора не сложно превратить в проверку флага на x86. Да придётся делать проверку каждой операции, только хардкор.

Ответить | Правка | Наверх | Cообщить модератору

148. "Анализ зависимости безопасности кода от используемого языка ..."  +1 +/–
Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 12:11 
> Ну так далеко не в каждой архитектуре есть способ обнаружить такое переполнение.
> Есть вполне стандартные конструкции для проверки переполнения,
> которые для компилятора не сложно превратить в проверку флага на x86.

С каждой строкой
нагнетается сайенс
хоть и не хокку.

Ответить | Правка | Наверх | Cообщить модератору

67. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Vkni (ok), 21-Дек-20, 01:33 
> он тем и хорош , что все под контроль программисту.

Есть чудесная статья "What every compiler writer should know about programmers" про то, что делают современные компиляторы из "портативного ассемблера". Например, сейчас, de facto, запрещены программы с Undefined Behavior, заточенные специально под конкретное поведение конкретного железа.

В качестве дальнейшего чтения могу предложить "C Is Not a Low-level Language".

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

70. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:44 
> Undefined Behavior, заточенные специально под конкретное
> поведение конкретного железа.

А при чём здесь железо?
Потеря контроля она и есть потеря контроля. "Железо" не поможет в такой ситуации. Поведение  имеет программа на C, а когда она его не имеет... >:-)

Ответить | Правка | Наверх | Cообщить модератору

137. "Анализ зависимости безопасности кода от используемого языка ..."  +1 +/–
Сообщение от Vkni (ok), 22-Дек-20, 01:46 
> А при чём здесь железо?

Почитайте статью. Для примера - под AIX/POWER вы можете разыменовывать NULL - он показывает на нулевую страницу. В результате, структуры типа

struct Tree {
   Tree *left;
   Tree *right;
   void *data;
};

можно отлично использовать с nullptr:

Tree * tree = nullptr;

tree->left == nullptr;
tree->right == nullptr;
tree->data == nullptr;

То есть, мы не должны проверять на nullptr лишний раз - это ускоряет программу.

Поскольку Цэ - это системный язык, он должен уметь использовать на 146% возможности конкретного железа. То есть, он должен уметь использовать это поведение системы.

> Потеря контроля она и есть потеря контроля. "Железо" не поможет в такой
> ситуации. Поведение  имеет программа на C, а когда она его
> не имеет... >:-)

Там нет потери контроля. Программа заточена под определённое железо, на нём она абсолютно предсказуемо работает, но современный компилятор, пользуясь UB перефигачивает её так, что она оказывается сломанной.

Ответить | Правка | Наверх | Cообщить модератору

139. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 02:13 
NULL не указывает "на нулевую страницу". Вы не поняли - железо ни при чём. Если у вас обнаружилось, что NULL "указывает на нулевую страницу", то это не "особенности железа". (скорее, это баг компилятора, поскольку оказывается, что NULL указывает на вполне правильную память и объект, который может оказаться и нужным). Для справки: NULL не обязан быть представлен нулевыми битами и определённо не должен быть представлен нулевым физическим адресом, если по этому адресу допустимо и возможно будет необходимо обращаться.
Ответить | Правка | Наверх | Cообщить модератору

142. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 02:43 
> Там нет потери контроля. Программа заточена под определённое железо, на нём она
> абсолютно предсказуемо работает, но современный компилятор, пользуясь UB перефигачивает
> её так, что она оказывается сломанной.

:-)))
Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железе.

То есть фактически вы пытаетесь основываться на особенностях компилятора (определённой версии и возможно ещё и определённого режима его работы). Вам кажется что программа должна работать определённо и без потери управления, но это вам только так кажется >:-) Как вы убедились. То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

150. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Ordu (ok), 23-Дек-20, 03:36 
> Смешное заявление: программа работает, но... не работает. При чём заметьте на том же железе

Да. Если взять компилятор из 80-х, будет работать. Если отключить оптимизации в современном компиляторе, будет работать. Если же современный компилятор и с оптимизациями, то работать не будет.

> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.

Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но сначала почитай.

В том-то и проблема, что предсказать поведение программы теперь невозможно, не учитывая всех тех UB описанных в стандарте, как UB.

Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось как "сделать то, что процессор делает при сложении целых". То есть, сложение в C было таким сложением, как его понимает CPU. Программисты на это полагались и C был задуман именно таким, чтобы программисты на это полагались: C был высокоуровневым ассемблером. Вдумайся в это: C был сделан именно таким с глубокой инженерной мыслью, предоставить программисту возможность писать "высокоуровневый" код, пользуясь при этом низкоуровневыми операциями, дать возможность программисту оставаться настолько близко к железу, насколько это возможно.

То есть, исходный C предполагал, что программист обладает этой "способностью к предсказанию" поведения кода с UB, на которую ты тут зубоскалишь. Знание программистом архитектуры даёт ему чёткое понимание того, что произойдёт при разадресации NULL. Или что произойдёт при переполнении целого.

Потом пришли современные техники оптимизации кода, которые выполняют оптимизацию многими фазами, и хоть каждая фаза вполне разумна, но в процессе трансформаций кода может теряться смысл выполняемых программой телодвижений, и затем вдруг -- хоп -- и UB становится русской рулеткой: что сделает отоптимизированная программа уже не угадать. Вплоть до дурацких ситуаций, когда UB спрятанный в if(condition) { here_UB(); }, присобачивает программе UB даже при !condition. (Хотя, вроде, такие вещи даже современные компиляторы C считают зашкваром).

Таким образом, C перестал быть высокоуровневым ассемблером. Он превратился в минное поле с разложенными по нему граблями. Теперь сложение С -- это не сложение CPU. На подавляющем большинстве машин целые числа хранятся в дополнительном коде (я, честно говоря, даже не знаю никаких современных процессоров, которые бы делали иначе). Но если я хочу использовать переполнение в своих целях -- например мне как раз нужна арифметика в кольце вычетов по модулю степени двойки, и мне пофигу что там случается с битами, которые вылетают за пределы диапазона, которые поддерживает int, мне главное чтобы достаточное количество младших бит сохранилось бы, -- то я не могу это писать на C. Мне придётся подключать ассемблер для таких вещей. Кстати, я давненько не читывал стандарт на C: они там не запилили в стандарт функций, для того, чтобы работать с переполнением без UB? Что-нибудь типа overflowing_add? Ведь куча крипты работает в кольцах по модулю степени двойки, им бы вовсе не помешало такое дополнение к стандарту.

То есть, современный C переопределил понятие UB, нагрузил его новой семантикой. Если раньше UB было чем-то таким, что неопределено ровно до тех пор, пока мы не определились с архитектурой, под которую пишем программу, а дальше оно чётко определено и предсказуемо, то теперь UB -- это карт-бланш компилятору на выполнение абсолютно любых преобразований кода. Теперь UB остаётся UB всегда, переполнение целого может запустить какой-нибудь builtin компилятора, взрывающий процессор, и типа так и надо, типа "ну а чё вы хотели, у вас же UB отклеился".

Ответить | Правка | Наверх | Cообщить модератору

151. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 23-Дек-20, 12:25 
О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.

> Да. Если взять компилятор из 80-х, будет работать. Если отключить оптимизации в
> современном компиляторе, будет работать. Если же современный компилятор и с оптимизациями,
> то работать не будет.

Что-то мне кажется вопрос скорее в том, как оно будет работать. И дело даже не в оптимизациях.

>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
> сначала почитай.

Незачем нам ходить. Вам упорно кажется, что поведение программ, поведение которых не определено, является определённым. И вы даже упорно пытаетесь довести это до нас. Компиляторы 80х внезапно не делают ваши примеры чем-то иным, поведение всё равно не определено.

> В том-то и проблема, что предсказать поведение программы теперь невозможно, не учитывая
> всех тех UB описанных в стандарте, как UB.
> Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось
> как "сделать то, что процессор делает при сложении целых".

Ага. Ordu начал рассказ, как следует трактовать C. Но сей пересказ того, как ему кажется следовало трактовать, значит в целом ничего.

> То есть, исходный C предполагал, что программист обладает этой "способностью к предсказанию"
> поведения кода с UB, на которую ты тут зубоскалишь.

:-))) Это очень плохое предположение. Хотя его и можно допустить. Результат можно наблюдать. Возможно так и было задумано. >:-)

> Знание программистом
> архитектуры даёт ему чёткое понимание того, что произойдёт при разадресации NULL.
> Или что произойдёт при переполнении целого.

Может быть и даёт кстати. Вот только Ordu уже похоже должен начать подозревать, что ему почему-то уже "не даёт". И надо будет приучаться жить с этим >:-)

> Потом пришли современные техники оптимизации кода, которые выполняют оптимизацию многими
> фазами, и хоть каждая фаза вполне разумна, но в процессе трансформаций
> кода может теряться смысл выполняемых программой телодвижений, и затем вдруг --
> хоп -- и UB становится русской рулеткой: что сделает отоптимизированная программа
> уже не угадать.

Короче, от использования "старого компилятора" программа не превращается в имеющую так сказать лучше определённое поведение. Просто получается пример с программой, не имеющей такового. Здесь следует ещё раз сказать, что такой пример не представляет собой чего-то эмпирически отличного, выглядеть может не хуже, а кому-то и лучше, любого примера работы с вполне определённым поведением :-) Мы уже высказались по поводу этого свойства.

> То есть, современный C переопределил понятие UB

Это опять конечно же не так.
Просто кое-кому приходится открыть для себя, что же это такое наконец. И это ещё с высокой вероятностью не конец >:-)

Ответить | Правка | Наверх | Cообщить модератору

152. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Ordu (ok), 23-Дек-20, 14:05 
> О, адвокат Файрфокса подтянулся, тоже то ещё вредоносное поделие.

Я что-то сказал в защиту фф? Где? Когда? Слабо найти хотя бы одну ссылку на мою защиту фф за последние 10 лет?

> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
> дело даже не в оптимизациях.

Именно в оптимизациях.

>>> То, что программа у вас в результате "работает предсказуемо", поскольку вы может быть способны как-то предсказать, как она будет работать, вовсе не значит определённого поведения. Ваши способности к предсказанию и определение поведения программы - вещи весьма разные.
>> Он дело советует -- сходи и почитай статьи, которые он рекомендует. Вот
>> сходи и почитай, и если останется желание позубоскалить, то зубоскаль. Но
>> сначала почитай.
> Незачем нам ходить.

Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы. А если тебе не интересно, что тебе говорят, то хренли ты лезешь разговаривать со взрослыми дядями? Мама с папой недостаточно внимания уделяют? Или в школе буллят и никто с тобой не общается?

Ответить | Правка | Наверх | Cообщить модератору

155. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 26-Дек-20, 03:25 
>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>> дело даже не в оптимизациях.
> Именно в оптимизациях.

Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес, как многим показалось (хотя может "работать" (и судя по написанному работало) и так). И это не "оптимизация".

> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.

:-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?

Ответить | Правка | Наверх | Cообщить модератору

156. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 26-Дек-20, 03:47 
Вот кстати "обоснование" выше приведённого примера с нулями (из тех, с которыми нам тут настоятельно советуют знакомиться) звучит довольно странно: "То есть, мы не должны проверять на nullptr лишний раз - это ускоряет программу." - намёк на некую оптимизацию, но... На самом деле непонятно где бы здесь была возможность для оптимизаций и ускорений, по крайней мере стоящих.
Ответить | Правка | Наверх | Cообщить модератору

157. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от n00by (ok), 26-Дек-20, 09:17 
>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес,

На современном железе программы работают с виртуальными адресами. И дело не в языке Си. Трансляция в физические происходит аппаратно через таблицу страниц. Боюсь, Вы банально путаете эти два понятия.

> как многим показалось

А что там на самом деле? Не макрос NULL, который "implementation-defined null pointer constant", а сама эта константа:

§6.3.2.3 Pointers

3 An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

162. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 28-Дек-20, 02:20 
> На современном железе программы работают с виртуальными адресами. И дело не в
> языке Си. Трансляция в физические происходит аппаратно через таблицу страниц. Боюсь,
> Вы банально путаете эти два понятия.

Есть один широко известный Адрес, который надо было бояться придётся следовать >:-)

Ответить | Правка | Наверх | Cообщить модератору

163. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от n00by (ok), 28-Дек-20, 09:20 
Абырвалг?
Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

158. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Ordu (ok), 26-Дек-20, 11:54 
>>> Что-то мне кажется вопрос скорее в том, как оно будет работать. И
>>> дело даже не в оптимизациях.
>> Именно в оптимизациях.
> Вы читали вышенаписанное? Там про NULL. И он не нулевой физический адрес,
> как многим показалось (хотя может "работать" (и судя по написанному работало)
> и так). И это не "оптимизация".

Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя этот пример сбивает с толку, я предложил поэтому иной -- целочисленное переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется, что принять этот пример ты всё равно не можешь, потому что ты веруешь в какую-то догму, и рефлексировать её не в состоянии.

>> Чувак, у тебя догма отклеилась. Если ты мыслишь догматично, хренли ты спорить лезешь? Никому неинтересны твои догмы.
> :-)) Ordu ввязавшемуся в спор неинтересно. И неприятно?

Естественно, когда спор ведётся по правилам детского сада, то есть по принципу: каждый участник повторяет своё утверждение многократно, и проигрывает тот, кому первому надоело.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

161. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 28-Дек-20, 02:12 
> Вообще-то, там обсуждается "под контроль программиста". NULL взят в качестве примера. Тебя
> этот пример сбивает с толку, я предложил поэтому иной -- целочисленное
> переполнение. Целочисленное переполнение, судя по всему, не сбивает, и тут выясняется,
> что принять этот пример ты всё равно не можешь, потому что
> ты веруешь в какую-то догму, и рефлексировать её не в состоянии.

Во-первых вам к Нам следует обращаться отнюдь не "ты".

Никакого примера с переполнением вы не предложили. Лишь высказались про переполнение и как  по-вашему должно работать сложение (во всяком случае похоже попытались - смотреть ниже). Про переполнение, не премину таки отметить, выше написал я.

Ну и поцитирую ещё вас: <<Взять, скажем, целочисленное переполнение. В C -- это UB. Которое исторически трактовалось как "сделать то, что процессор делает при сложении целых".>>. Весёлая цитата, свидетельствующая о незагруженном лишними догмами мышлении - попробуйте вдуматься, что вы здесь написали.

Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на юмор :-)

Ответить | Правка | Наверх | Cообщить модератору

164. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Ordu (ok), 28-Дек-20, 12:41 
> Ну считайте таким образом свой бред про догмы и рефлексирование оных отмеченным
> и даже удостоенным какого-никакого но не совсем несерьёзного ответа, несмотря на
> юмор :-)

Ох блин, спасибо, вот уважил старика. Как я надеялся, что ты прочитаешь, и ты прочитал /s

Дурень, твоё мышление -- это твоё мышление, это твой рабочий инструмент, твоё средство для выживания в этом мире. Задачивать его в твоих интересах, а не в моих.

Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

68. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 21-Дек-20, 01:33 
> Проблемы C++ от того, что его упорно смешивают с Си.

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

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

117. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от PnD (??), 21-Дек-20, 15:18 
По моему опыту всё, на чём я (и не только) писал могло оказаться неправильным. И (в принципе) таковым остаётся пожизненно, т.к. математическое моделирование (выливающееся в покрытие тестами) также допускает ошибки.

ASM: Неверное применение инструкций (даже так бывает). Т.к. в современных системах мало справочник перелистать.
ASM,*sh,php: Смешивание кода и данных. Причины разные, а проблемы одни.

С (в моём случае это обычно libc, хотя даже дёргай я напрямую за syscall, как в go поступают — то же самое будет): Опять таки, неверные сценарии работы (с posix). Не обеспечил "wait()" после завершения форка — здравствуй, зомби.

С++ (не моё): Многие начинающие пытаются писать "олимпиадный" код. Потому что "круто".

Go: Всё про параллелизм провоцирует трудно отлаживаемые ошибки. 90% мог бы вычистить стат. анализатор, но его нет. Вплоть до анекдотов, когда мьютекс объявлен внутри функции которую должен контролировать (не всю, но не важно). И "замыленный" глаз это не видит. Также прослеживается тенденция "переписать на безопасном go" (dns, ssl). С неизбежным внесением ошибок в логику.

Perl: Легко написать медленный код, не разобравшись в слабостях языка. Хуже того, некоторые вещи (треды) могут работать не так как ожидается из документации. А отлаживать параллельное выполнение на языке который изначально был не про это — ну так себе.

Python (с 3.х — только "одноразовый" код): Попытка сумничать (ну, язык-то позволяет) порождает откровенный идиотизм.

Все "высокоуровневые" языки (у меня "под боком" — java и erlang): Провоцируют пишущего чувствовать себя "в домике". Код "складывается" под нагрузкой самыми причудливыми образами.

…Короче, побрюзжал. Можно идти дальше писать на том что "под рукой". И хорошо, когда это не авионика для "Боингов".

Ответить | Правка | Наверх | Cообщить модератору

132. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от Myyx (?), 21-Дек-20, 22:58 
ну так гёдель же еще 100 лет тому назад ...
так шо не парься все ошибаются и я тоже (черт. рекурсия)
Ответить | Правка | Наверх | Cообщить модератору

143. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 03:19 
> По моему опыту всё, на чём я (и не только) писал могло
> оказаться неправильным.

Могло, может быть. Но только годное и работоспособное не могло. То, на чём вы писали. Кроме может быть C. :-)
То, что вы писали - это уже очень другое.

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

144. "Анализ зависимости безопасности кода от используемого языка ..."  +/–
Сообщение от АЛМНКАГОГ (?), 22-Дек-20, 03:22 
> Кроме может быть C. :-)

...а также, извините, Питона, Явы, Perl, Go... >:-)
(тот ещё набор)...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру