Ну согласитесь все же, что языков с символами только из ASCII все же в разы меньше, чем таковых из UCS2. Собственно, мне, кроме английского, ничего в голову не приходит — да и там встречаются слова вроде naïve, плюс заимствования из испанского с ñ в американском английском.
>> а в левой стороне мы НЕ получим результата, но при этом будет выброшено исключение.
Это вопрос терминологии. Если исключение считать результатом (т.е. если рассматривать любое выражение в языке как Succes(value)|Error(exception), то все ок. Просто семантика == в данном случае не эквивалентна нормальной функциональной, но это уже другой разговор.
А какая вам разница, что по одной-две единицы хранения на символ (UTF-16), что по одной-шести (UTF-8)? Что так, что так нужно работать с переменной длиной.
Зато в UTF-8 этот факт почти для всех очевиден. А вот UTF-16 для очень многих символов позволяет допущение одно слово = один символ, и в итоге люди пишут сломанный код, не зная об этом.
Тут проблема в том, что две основные десктопные ОС хотят именно UTF-16, а конвертирование несколько неудобно, да и накладные расходы добавляет. Хотя жизнь, несомненно, была бы проще, если бы везде было UTF-8.
Если вы хотите что-то максимально полезное вынести — начните не с нулевых указателей, а с некорректного использования sizeof/SIZEOF, и прочих багов с подсчетом кол-ва элементов.
>> Как вы думаете если у нескольких миллионов пользователей за несколько лет в этом месте ничего не падало, то каковы шансы что этот указатель окажется NULL?
Эти шансы вполне могут оказаться стопроцентными, когда вы, например, обновитесь на новую версию компилятора, которая решит креативно соптимизировать данный кусок кода, поскольку там все равно U.B. gcc этим особо славен, но MSVC тоже иногда может.
>> Лично я предпочитаю не находить ошибки, я предпочитаю их исправлять. Я больше ценю багрепорт юзера нашедшего ОДИН сценарий при котором чтото упадет. Чем такой вот отчет о том что мы нашли кучу косяков в коде из-за которого «МОЖЕТ» упасть, а может и не упасть, ибо код просто недостижим или вообще заброшен и лежит тут для истории.
Facepalm. И эти люди пишут сетевые клиенты. Которые получают и обрабатывают данные хз откуда. И как они их обрабатывают — мы видим на примере данной статьи.
Вам фраза «удаленное выполнение кода» о чем-нибудь говорит?
Ппц. Судя по продемонстрированному коду, а еще в большей степени — по реакции на него, Миранду использовать нельзя ни в коем случае, потому что вероятность того, что через неё вас удаленно отэксплойтят, резво стремится к единице.
>> На самом деле, разница есть. Потому что конструктор производного класса этот указатель исправит.
Это настолько деталь реализации, что полагаться на это — не стоит ни разу. Например, в производном классе может не быть виртуальных функций, и нигде в программе нет динамических проверок на данный тип — тогда и указатель не нужно обновлять. Или оно может попробовать дернуть что-то через этот указатель до его обновления. Да мало ли что… U.B. — это U.B., не надо пытаться его обыграть.
Переносимость — это portability. Interoperability — это совсем другое, и на русском эквивалента в одно слово нет (ну или есть в виде такой вот кальки — кстати, ру-вики с ней согласна).
В .NET 4.6 RyuJIT по умолчанию (т.е. уже не бета), но старый пока оставили как опцию. В перспективе — да, его тоже выпилят когда-нибудь, но некоторое время будет поддержка обоих.
Так вроде об этом и разговор выше по треду — что новый улучшенный JIT можно изначально зарелизить как альтернативу, чтобы не ломать легаси (как это и сделали для RyuJIT), а потом уже назначить его основной реализацией, и дропнуть старую еще через релиз.
Это вопрос терминологии. Если исключение считать результатом (т.е. если рассматривать любое выражение в языке как Succes(value)|Error(exception), то все ок. Просто семантика == в данном случае не эквивалентна нормальной функциональной, но это уже другой разговор.
Зато в UTF-8 этот факт почти для всех очевиден. А вот UTF-16 для очень многих символов позволяет допущение одно слово = один символ, и в итоге люди пишут сломанный код, не зная об этом.
Это многое объясняет.
Эти шансы вполне могут оказаться стопроцентными, когда вы, например, обновитесь на новую версию компилятора, которая решит креативно соптимизировать данный кусок кода, поскольку там все равно U.B. gcc этим особо славен, но MSVC тоже иногда может.
Facepalm. И эти люди пишут сетевые клиенты. Которые получают и обрабатывают данные хз откуда. И как они их обрабатывают — мы видим на примере данной статьи.
Вам фраза «удаленное выполнение кода» о чем-нибудь говорит?
Ппц. Судя по продемонстрированному коду, а еще в большей степени — по реакции на него, Миранду использовать нельзя ни в коем случае, потому что вероятность того, что через неё вас удаленно отэксплойтят, резво стремится к единице.
А то, что в контракт там входит еще и длина, это есть только на уровне документации.
Это настолько деталь реализации, что полагаться на это — не стоит ни разу. Например, в производном классе может не быть виртуальных функций, и нигде в программе нет динамических проверок на данный тип — тогда и указатель не нужно обновлять. Или оно может попробовать дернуть что-то через этот указатель до его обновления. Да мало ли что… U.B. — это U.B., не надо пытаться его обыграть.
Так что не торопитесь хоронить эту идею. Все может быть.