V>Лично меня напрягает то, что сам драйвер протестирован и подписан мелкомягкими, т.е., скорее всего, протестирован достаточно хорошо.
гм. Это не совсем так работает. Тестирование там очень-очень поверхностное. По крайней мере раньше так было. Может, сейчас как-то иначе, но — сомневаюсь.
Подпись не означает "протестировано". Это означает, что "зуб даем, вот тот бинарь нам пришел от кого-то из crowdstrike, у кого есть приватный ключ для подписи". В общем-то, ничего более. Что уж там, я не удивлюсь, если подписываемый драйвер не тестируется от слова вообще (кроме как базовых статических тестов).
Здравствуйте, Codealot, Вы писали: C>Ты гонишь пургу. Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой.
Да там и всё остальное — пурга. Вот буквально каждое предложение бери — и там вранье.
Совсем парень переехал в параллельную реальность, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
V>>А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг... C>Ты гонишь пургу.
Это ты гонишь пургу.
А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий.
Лицензия самая полная из всех доступных.
C>Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой.
Так "не отваливается" или "это не проблема"?
Это проблема, бо периодически создаёт задержки, пока он там автоматически переподгрузит рухнувшую подсистему.
Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух?
Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг...
Здравствуйте, Sinclair, Вы писали:
C>>Ты гонишь пургу. Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой. S>Да там и всё остальное — пурга. Вот буквально каждое предложение бери — и там вранье.
Конкретней, мистер болтун.
Это где ты занимался очковтирательством в своём "генераторе кода на лету"?
Или что NRE возник в байт-коде конкретно по проблеме этого топика?
Или что ненадёжный багованный Решарпер падает много раз за рабочий день?
Так с чем именно ты всё ещё не согласен?
S>Совсем парень переехал в параллельную реальность, увы.
Скорее, кто-то скромно отворачивается, предпочитая не замечать проблем, связанных с новомодным этим идиотизмом под названием "фричество".
Да забей ты на эту херню уже, пора уже было вырасти из детских штанишек.
Это ж пипец несерьёзно — ты что в 25 лет щенячьими глазками смотрел на мир, что до сих пор.
Ничему тебя жизнь не учит...
И не научит до тех пор, пока предпочитаешь отворачиваться, не замечать, убегать/избегать, одним словом — бояться жить.
"Пусть этим занимается кто-то другой" — это твой такой подход, весьма чистоплюйский, кстате.
ОК.
Ну тогда твоя задача внимательно внимать опыту этих других людей, а не устраивать капризы на весь инет в духе "А баба Яга против!". ))
Здравствуйте, vdimas, Вы писали:
V>NRE произошёл не в С/С++ )) V>Хватит уже распускать слухи.
Конечно же в C/C++
Официально это теперь не nre, а
out-of-bounds memory read, но это ничего в лучшую для сишечки сторону не меняет.
V>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch.
setjmp/longjmp тут конечно не в тему. Но да на винде есть SEH который позволяет ловить NRE на си. Но как всем известно программисты на сишечке не обрабатывают ошибки 🤷🏿♀️ И это просто очередной пример.
Здравствуйте, vdimas, Вы писали:
V>А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий.
Я тебе уже сказал. У меня он отваливался в последний раз, наверно, в прошлом году.
V>Так "не отваливается" или "это не проблема"?
Нет такой проблемы, чтобы он вообще отваливался. Так лучше доходит?
V>Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух? V>Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг...
Если очень захотеть, то наверняка можно этого добиться. В крайнем случае, залезть в бинарные файлы и подшаманить.
у меня такой проблемы нет. У всех моих знакомых тоже нет. Похоже, что она есть только у тебя.
Здравствуйте, Codealot, Вы писали:
V>>А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий. C>Я тебе уже сказал. У меня он отваливался в последний раз, наверно, в прошлом году.
А в течение 15 лет до этого? ))
C>Нет такой проблемы, чтобы он вообще отваливался. Так лучше доходит?
Что не соответствует наблюдаемому.
Может, у вас код "более стандартный", бгг?
V>>Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух? V>>Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг... C>Если очень захотеть, то наверняка можно этого добиться. В крайнем случае, залезть в бинарные файлы и подшаманить.
Ой, давай без этого.
Я не заинтересован в глючности инструментария.
C>у меня такой проблемы нет. У всех моих знакомых тоже нет. Похоже, что она есть только у тебя.
И у других коллег, с которыми работаю.
Ну так что, слать тебе ежедневно по нескольку скриншотов глюканутого Решарпера?
Или уже угомонишься и просто примешь инфу к сведению? ))
Здравствуйте, Константин Б., Вы писали:
V>>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch. КБ>setjmp/longjmp тут конечно не в тему.
В смысле?
Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp.
Здравствуйте, vdimas, Вы писали:
V>Может, у вас код "более стандартный", бгг?
То есть в смысле, что у вас там он черезжопный.
V>Ой, давай без этого. V>Я не заинтересован в глючности инструментария.
Ты явно заинтересован в том, чтобы не выглядеть треплом.
V>Или уже угомонишься и просто примешь инфу к сведению? ))
Ну ок, приму к сведению, что у некоторых любителей каких-то черезжопных вещей бывают странные баги и они на этом основании делают далеко идущие выводы.
Здравствуйте, vdimas, Вы писали:
V>Конкретней, мистер болтун. V>Это где ты занимался очковтирательством в своём "генераторе кода на лету"?
Это очковтирательство по скорости порвало GCC с -o3, при этом не жертвуя контролем диапазонов.
А вы, коллега, усердно тупили, не понимая, чем банальное завёртывание unsafe кода в "safe" обёртку отличается от нормальной статической верификации корректности кода.
V>Или что NRE возник в байт-коде конкретно по проблеме этого топика?
NRE возник в VM, которая пытается интерпретировать байт-код.
Сказки о том, что BSOD является ожидаемым поведением, рассказывайте первокурсницам гумфака. Скормили тебе сигнатуру с ошибкой — записал об этом в лог, пошёл следующую сигнатуру проверять.
Впрочем, от человека, который не понимает, как типизируются промежуточные результаты в выражениях С++, я понимания столь сложных вещей и не ожидаю.
V>Скорее, кто-то скромно отворачивается, предпочитая не замечать проблем, связанных с новомодным этим идиотизмом под названием "фричество". V>Ну тогда твоя задача внимательно внимать опыту этих других людей, а не устраивать капризы на весь инет в духе "А баба Яга против!". ))
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Б., Вы писали:
V>>>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch. КБ>>setjmp/longjmp тут конечно не в тему.
V>В смысле? V>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp.
А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос). А longjmp руками вызвать надо.
Здравствуйте, Codealot, Вы писали:
V>>Может, у вас код "более стандартный", бгг? C>То есть в смысле, что у вас там он черезжопный.
О, пошла стадия торга, бгг...
V>>Ой, давай без этого. V>>Я не заинтересован в глючности инструментария. C>Ты явно заинтересован в том, чтобы не выглядеть треплом.
Я даже не думал в эту сторону, но вот ты окончательно затрепался, опять бгг...
Это ж надо придумать, чтобы я влез в бинари Решарпера и пошаманил там эдаким образом, чтобы сохранить работоспособность, но чтобы он иногда глючил.
Ты там под веществами был, что ле? ))
V>>Или уже угомонишься и просто примешь инфу к сведению? )) C>Ну ок, приму к сведению, что у некоторых любителей каких-то черезжопных вещей бывают странные баги и они на этом основании делают далеко идущие выводы.
1. Баги не у меня, а у Решарпера, третий раз бгг...
2. Наш код вполне корректен синтаксически и логически, хотя да, нетривиален с т.з. большинства дотнетных поделий;
3. Выводы не далекоидущие, а самые прямые — основная масса дотнетчиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети, заключительное бгг...
Здравствуйте, Константин Б., Вы писали:
V>>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp. КБ>А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
Вызывается изнутри _Unwind_RaiseException — сначала производится cleanup текущих стековых переменных, затем поиск обработчика через type_info, затем происходит аналог longjmp на установленную точку входа обработчика.
КБ>В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос).
В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение.
Т.е., сводит сигналы различной природы к одному АПИ.
КБ>А longjmp руками вызвать надо.
longjmp — это невыразимый обычными ср-вами языка трюк "отмотки" стека с одновременной передачей управления некоей выставленной заранее точке в коде, где указатель стека как раз восстанавливается до значения в этой точке.
Пробрасывания и перехваты исключений построены ровно по такому же принципу, разве что вместо аргумента int user_data оперируют указателями на void*, под которым скрываются более сложные структуры, описывающие семантику происходящего. При доступе к АПИ компилятора на Си нефик делать всё это раскрутить вручную, как это происходит автоматом на плюсах.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Б., Вы писали:
V>>>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp. КБ>>А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
V>Вызывается изнутри _Unwind_RaiseException ...
А _Unwind_RaiseException кто вызовет?
КБ>>В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос).
V>В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение. V>Т.е., сводит сигналы различной природы к одному АПИ.
Да. В SEH понятно кто что вызывает. А кто вызывает _Unwind_RaiseException/longjump?
КБ>>А longjmp руками вызвать надо.
V>longjmp — это ...
Я знаю что оно такое и что делает. Вызывает-то его кто?
Здравствуйте, Sinclair, Вы писали:
V>>Это где ты занимался очковтирательством в своём "генераторе кода на лету"? S>Это очковтирательство по скорости порвало GCC с -o3, при этом не жертвуя контролем диапазонов.
Порвало оно наивную реализацию, а так-то отсосала от ненаивной.
Но не в этом дело, мне там на скорости было малость до фени, я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях.
Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай.
Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками.
S>А вы, коллега, усердно тупили, не понимая, чем банальное завёртывание unsafe кода в "safe" обёртку отличается от нормальной статической верификации корректности кода.
Опять начались изворачивания...
Сходи да освежи. ))
Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать.
В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают.
С тобой почему не так?
Я не вижу простого рабочего подхода при решении тобой технических задач.
Беспокойная твоя головушка создаёт слишком много лишнего информационного шума, который никому нахрен не нужен.
Такое ощущение, что ты не работу работаешь, не стремишься к результату, а тупо ждёшь как ребёнок похвалы за каждое своё телодвижение.
Т.е. сосредоточен сугубо на комфортном процессе, а не на результате, бгг...
Смотреть на это невозможно, испанский стыд.
Перехвалили в детстве? ))
V>>Или что NRE возник в байт-коде конкретно по проблеме этого топика? S>NRE возник в VM, которая пытается интерпретировать байт-код.
Ошибка была в самом байт-коде.
S>Сказки о том, что BSOD является ожидаемым поведением
Ожидаемым поведением ошибки ядерного уровня, ес-но.
Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит.
S>Скормили тебе сигнатуру с ошибкой — записал об этом в лог, пошёл следующую сигнатуру проверять.
Нахрена?
Чтобы "отформатировать диск"? (С)
Нормальным поведением будет вывалиться с ошибкой, а не пытаться исполнять какую-то чухню.
Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
"Зацикливание" всего сценария случилось на вышестоящем уровне, напомню, что я тоже высмеял.
(Хотя, в 90-е никто не парился, а просто заходили в отладочном режиме и откатывали последние обновления, просто сейчас средняя по палате компьютерная грамотность чудовищно низка)
А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
В общем, высмеиваю тебя за это повторно — ты опять сам себя сдаёшь как стеклотару.
Показываешь перлы своего "объективного мышления", бгг...
S>Впрочем, от человека, который не понимает, как типизируются промежуточные результаты в выражениях С++, я понимания столь сложных вещей и не ожидаю.
Ты опять заврался.
Я же тебе продемонстрировал в чём дело — сохранил результат в промежуточную стековую volatile-переменную (семантика volatile в плюсах иная, чем в дотнете).
В итоге, UB никуда не делся, но битовые фокусы стали ожидаемыми тобой.
И я продемонстрировал тебе суть происходящего и на C#, чем подорвал твой анус, помнится.
Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
Никакой другой причины впадения тебя в неадекват и проявляемой затем мстительности не было.
Ну выставили тебя болтуном и что?
Первый раз, что ле?
Ну вот манера у тебя такая — еще не разобрался, а уже пошёл поливать грязью "классовых врагов". ))
Жалкое зрелище, бо мы к тебе во враги не записывались, бгг...
Это ты сам, сам — глубинные комплексы покоя не дают.
Всего-то достаточно в другой раз следить за языком.
Но ты не можешь — вот как здесь опять нагородил чухни не разобравшись.
============
И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
Впрочем, компиляторы делали это и до фиксирования в стандарте.
Но теперь это допустимо и просто для локальных объектов, бо согласно последнему стандарту их не требуется "воплощать" без лишней надобности, т.е. их официально приравняли к промежуточным значениям вычислений. Впрочем, компиляторы и это делали еще до фиксации в стандарте.
Это всё способы, во-первых, улучшить точность вычислений, а во-вторых — не натыкаться лишний раз на UB в случае переполнений.
Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
До тех пор, пока от этого не страдает семантика well formed кода — это допустимо и правильно.
И да, повторю свою мысль — когда-то это всё дойдёт и до дотнета, несмотря на твой визг "низачто и никогда!"
Сам прикинь — сейчас ситуация в дотнете с нейтивной кодогенерацией примерно как в конце 80-х / начале 90-х на С/С++, когда компиляторы компиляли в точности как написано, бгг...
Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
Здравствуйте, Константин Б., Вы писали:
V>>Вызывается изнутри _Unwind_RaiseException ... КБ>А _Unwind_RaiseException кто вызовет?
Его вызывает ф-ия __cxa_throw — это "высокоуровневый" хелпер для запуска исключения, т.е. чтобы конструкция throw компилялась в малое кол-во опкодов.
Унутре __cxa_throw инициализирует локальные данные потока объектом-исключением и текущим контекстом функции и вызывает _Unwind_RaiseException.
Затем изнутри __cxa_throw (или по возврату из неё — в зависимости от реализации) вызывается:
__builtin_eh_return (offset, handler), which adjusts the stack by offset and then jumps to the handler.
Или другой аналог longjmp.
Там ключевое отличие лишь в том, что setjmp вызывается коде динамически, т.е. некий твой код динамически заполняет структуру jmp_buf, а компилятор генерит таблицу уже заполненных аналогичных структур для ф-ии еще в процессе компиляции.
V>>В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение. V>>Т.е., сводит сигналы различной природы к одному АПИ. КБ>Да. В SEH понятно кто что вызывает. А кто вызывает _Unwind_RaiseException/longjump?
Примерно так:
throw SomeException();
; передача аргументов в x64_call: RDI, RSI, RDX, RCX...
mov edi, sizeof(SomeException)
call __cxa_allocate_exception
mov rbx, rax
mov rdi, rax
call SomeException::SomeException()
; __cxa_throw(void *thrown_object, std::type_info *tinfo, void (*dest)(void *))
mov rdx, SomeException::~SomeException()
mov rsi, typeid(SomeException)
mov rdi, rbx
call __cxa_throw
; далее зависит от реализации - где происходит вызов деструктора исключения -
; внутри __cxa_throw или реализация разбита на две фазы
mov rdi, rbx
mov rbx, rax
call __cxa_free_exception
// если по возвращении, то вызываем вторую фазу обработки исключения
mov rdi, rbx
call _Unwind_Resume ; внутри будет вызван аналог __builtin_eh_return
V>>longjmp — это ... КБ>Я знаю что оно такое и что делает. Вызывает-то его кто?
Здравствуйте, vdimas, Вы писали: V>Порвало оно наивную реализацию, а так-то отсосала от ненаивной.
А что вы имеете в виду под "ненаивной"? V>Но не в этом дело, мне там на скорости было малость до фени, я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях.
И в каких же случаях он "порет лажу"?
V>Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай. V>Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками.
V>Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать.
В реальности вы там начали нести пургу, за которую были высечены несколькими участниками.
V>В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают.
Напомните-ка мне, в чём там некорректность? А то дело уж давно было, я малость подзабыл.
V>Я не вижу простого рабочего подхода при решении тобой технических задач. V>Беспокойная твоя головушка создаёт слишком много лишнего информационного шума, который никому нахрен не нужен.
V>Перехвалили в детстве? ))
Скорее вас недохвалили. Отсюда постоянные попытки, обосрамшись, сделать вид, что "ничего не было", на крайняк "меня не так поняли".
V>Ошибка была в самом байт-коде.
Несомненно была.
V>Ожидаемым поведением ошибки ядерного уровня, ес-но. V>Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит.
V>Чтобы "отформатировать диск"? (С)
Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.
Основное преимущество управляемого кода — как раз возможность изолировать ошибки.
V>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
V>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.
V>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.
V>Ты опять заврался. V>Я же тебе продемонстрировал в чём дело — сохранил результат в промежуточную стековую volatile-переменную (семантика volatile в плюсах иная, чем в дотнете). V>И я продемонстрировал тебе суть происходящего и на C#, чем подорвал твой анус, помнится.
V>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс, зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?
V>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
Ну вот, вы продолжаете позориться. Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.
За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.
V>Это всё способы, во-первых, улучшить точность вычислений, а во-вторых — не натыкаться лишний раз на UB в случае переполнений.
V>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.
Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.
V>И да, повторю свою мысль — когда-то это всё дойдёт и до дотнета, несмотря на твой визг "низачто и никогда!" V>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
Впечатляющий пример глобального непонимания.
1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.
2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.
3. Не понимаете причин, по которым компиляторы С++ делают именно так. Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".
4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях. S>И в каких же случаях он "порет лажу"?
Ты потерял тот топик? ))
Меня триггернуло даже не в то, что код неверный для большого класса сценариев, а что об этом даже не сигнализируется.
Ну и, ты в привычной своей манере стал трепать нервы, делая вид, что проблема несущественная. ))
Хотя, у потенциального юзера твоей либы должен был возникает вопрос — а как же оно тогда скомпиллировалось, если неверно работает?
А вот так.
Динамика — штука подлая. ))
Т.е., стоило бы тебе быть честным с самим с собой еще на этапе продумывания того, как это будет выглядеть на самом верхнем уровне.
Тогда ты бы выбрал другую стратегию реализации — ведь на тот момент уже был доступен Рослин, т.е. можно было делать кодогенерацию времени компиляции и сообщать о невозможности реализовать оптимизированный вариант на этой стадии.
(или же скатываться к некоему менее оптимальному fallback)
По крайней мере, такое решение могло бы не уйти "в стол", а постепенно развиваться.
А твой подход — заведомый тупик из-за взрывного роста комбинаторной логики в попытках обыграть всевозможные граничные случаи, при том что код кодогенерации наглухо нечитаемый/неподдерживаемый. И ты тоже заранее знал, что подобный код — это классическая лапша.
Плюс, "захватывать" аж всю сигнатуру 2D-массивов для linq единственной спорной реализацией — такое себе...
Решение не пострадало бы от введения доп. типа-маркера для Рослина, а даже выиграло бы, бо при таком подходе могло бы сосуществовать более одной реализации/стратегии.
Вот и получается, тебе просто захотелось поиграться, ты достиг неких результатов и поспешил "размазать сишников".
А вот не надо было торопиться, сначала надо было исследовать полученное.
И тем более не надо было агрить сишников в топик, они тут уже точно не при чём. ))
Но ты многократно упомянул всуе, и как всегда далёким от корректности образом, но так смешно вышло, что единственный, кто вникнул и целиком разобрался был сишник, а не обычные посетители C# топика. ))
И сдаётся мне, этот забавный факт сильно повлиял на дальнейшее общение, бгг...
Ведешь себя порой, блин, как блоггер моды или даже профессиональный артист.
V>>Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай. V>>Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками. S>
Ничего смешного.
В таких случаях коллеги реагируют на порядки короче: "Ой, точно!"
V>>Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать. S>В реальности вы там начали нести пургу, за которую были высечены несколькими участниками.
Ага, побегай, "реальность на месте", можно полюбоваться.
Что я неверно изобразил тестовый пример в самом первом своём сообщении в том топике, дык, я и сказал своё "ой" и тут же исправился — и оно ни на что не влияло, т.к. рассматривались методы решения задач этого класса, а не конкретная задача — иначе бы тебе не было смысла городить свою либу.
Да, в момент написания одного из первых ответов был сосредоточен на другом, и?
Оно на что-то повлияло в обсуждении?
Аж ни на что. ))
Я-то свой косяк мгновенно тут же исправил (а мог бы и не исправлять, бо абсолютно было пофик как при обсуждении как твоей реализации, так и моих предлагаемых альтернативных приёмов), а у тебя суровый косяк как был, так и остался неисправленным до сих пор.
Вот и вся разница между нами, бгг...
V>>В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают. S>Напомните-ка мне, в чём там некорректность? А то дело уж давно было, я малость подзабыл.
Подробности на месте, но они всё так же маловажны.
Спустя кучу постов ты-то согласился...
Думаю, вряд ли многие коллеги до туда дочитали, бгг...
Я ж не к конкретной ошибке цепляюсь, а в целом к паттерну действий.
Помнится, про драйверы баз данных примерно оно же вышло — ты рассуждал о желаемом как об имеющемся, вынудил меня сделать кучу проверок, чтобы убедиться, что ты прилюдно врёшь как дышишь.
Да, такие вещи раздражают и реакция соответствующая.
Это ж неделовой подход — ты сначала что-то громко рекламируешь, а в итоге выясняется, что тупо воруешь время.
А как же одно из первых твоих сообщений на RSDN об этике инженера?
Это ты сам себя уговаривал, получается, и так и не уговорил до сих пор? ))
Кароч.
Все мы можем ошибаться, я тут не видел ни одного человека, который ни разу бы прилюдно не ошибся.
В реале тем более не видел.
Это наша фича, а не баг.
Баг у некоторых заключается в интерпретации этой фичи. ))
И еще багом у некоторых является тяга к противопоставлению технологий.
Заметь, я противопоставляю не технологии, а подходы к решению задач, сам менталитет инженера-разработчика.
И ты ж должен знать, что многие нейтивные программеры пишут не только нейтивный код.
Что как минимум еще зачастую сопрягают его со скриптовыми или управляемыми языками, как раз выполняя работу изнутри кишок "более прикладных" технологий, т.е. зная и понимая их тонкости.
И что сами эти "более прикладные" технологии почти никогда не критикуются (кроме совсем уж вопиющих моментов, когда плавучку на дотнете даже не пытались оптимизировать в течении 20-ти лет, а потом сделали буквально с полутыка для Core — конкретно мне это навредило в одном из исследовательских проектов, который делал на шарпе, что пришлось уйт ив нейтив и отказаться от кое-какой важной задумки).
Что чаще критикуются неверные ожидания от технологий, ведь неверные ожидания часто приводят к неверным принимаемым решениям.
В общем, очковтирательство — это самое большое преступление инженера, конечно.
Не зря "оно" обыгрывается практически во всех пунктах "инженерной этики", потому что этих очковтирательств много разных — можно врать о мотивах своих принимаемых решений, можно врать о потенциале технологии, можно врать о решениях конкурентов и т.д.
Но врать нельзя.
Ошибаться, исправлять ошибки — можно (обязательно делая работу над своими ошибками, бгг...)
Врать нет.
Просто вы воспринимаете объективные аргументы как нападки на технологии.
И вот это уже "ой".
Простое перечисление характеристик не может быть нападками.
Если вы видите здесь нападки, значит, проблема не в технологиях, а в психике видящих.
Да, над этим периодически стебёмся, бо это ж реально смешно — нахрена тогда вообще в IT сунулись? ))
Я уверен, что пишу кода на Шарпе на порядок-другой больше тебя в течении всех лет его существования.
Простое перечисление характеристик технологий не вызывает у меня батхерта.
Почему вызывает у тебя?
Причём, в клинической его форме, когда ты снова и снова, безо всякого провоцирования, по каждому малейшему поводу пытаешься воевать с виртуальными своими оппонентами? ))
Со стороны — какая-то разновидность мазохизма.
Здравствуйте, vdimas, Вы писали:
V>Это ж надо придумать, чтобы я влез в бинари Решарпера и пошаманил там эдаким образом, чтобы сохранить работоспособность, но чтобы он иногда глючил.
В интернете много упертых идиотов, и не такое бывает.
V>2. Наш код вполне корректен синтаксически и логически, хотя да, нетривиален с т.з. большинства дотнетных поделий;
То есть, черезжопный.
V>3. Выводы не далекоидущие, а самые прямые — основная масса дотнетчиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети, заключительное бгг...
А у меня, например, виртуалбокс нередко падает со странными ошибками. Из чего следует прямой вывод, что основная масса системшиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети
