Журнал Витуса

А можно профанский вопрос, от человека, который никогда не писал ничего "системного"(tm) и уже очень давно не писал ничего сложнее обработки логов перловым скриптом: для чего вообще могут быть нужны такие фокусы ?

Edited Date: 2016-04-05 08:35 am (UTC)

From:

livelight

Чтобы поприкалываться, а заодно иногда сэкономить байт и наносекунду :)
Google: Obfuscated C contest

From:

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

From:

Я правильно понимаю, что продолжение этой вполне здравой логики приведет нас к реизобретению паскаля ? ;-)

From:

Паскаль уже переизобрели. Java называется.

From:

Оно периодически случается. Ява - наиболее яркий случай.

From:

slobin.livejournal.com

Ява -- нихрена не новый Паскаль. Она могла бы стать новым Паскалем (ничего в самом ЯЗЫКЕ этому не препятствует), если бы выжила, условно говоря, линия gjc -- компиляция в отдельно стоящий исполняемый файл, без многомегабайтного рантайма и с мгновенным запуском. Ещё раз -- с Явой такое сделать можно, и было реально сделано. Но не прижилось.

А новым Паскалем окажется, я надеюсь, какой-нибудь из языков "новой волны". Более-менее неважно какой, любой из них лучше, чем сложившаяся сейчас ситуация. Да хоть бы та же няшная Гошечка. :-) (хотя у него, разумеется, свои недостатки, но у кого их нет? И, кстати, "язык слишком бедный, в нём нет того, того и вон того" к недостаткам не относится).

... Ледяные ласки огненных лисиц ...

From:

Всё, для чего в копмпиляторе не определено точное поведение, но при этом может быть написано программистом, откомпилировано и исполнено, это источник:
- ошибок обновления компилятора. Так как сегодняшняя версия компилирует один код, а завтрашняя - другой. Просто из-за того, что поведение undefined - никто не тестировал.
- ошибок обновления кода. Опять же - при редактировании собственной программы автор не задумывается о данном кусочке, ичто он изменит работу.
- ошибок несовместимости архитектур ПРОЦЕССОРА - "на x86 работаем, на x64 нет" хотя бы
- ошибок различия сред исполнения. Пример из реальной жизни - одна и та же ДОС/Win95 программа, запущенная в досбокс в современной Windows. Ещё смешнее - одна и та же программа, запущенная в английской и русской версиях операционки. Достаточно ОДНОГО национального символа в одном пути к файлу чтобы получить потрясающие спецэффекты.

Edited Date: 2016-04-05 09:08 am (UTC)

From:

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

А через двадцать лет появляется новый компилятор который на это говорит "фу". Я тут было дело недавно правил подобного рода конструкцию в catdoc. Не помню зачем я ее написал во времена turbo C 2.0, но вот CLang на 64-битной архитектуре жрать отказался.

Но вообще когда у тебя "на x86 работаем, а на x64 нет", это полбеды. Вот когда "на x86 работаем, на x64 работаем, на ARMv5 работаем, а на ARMv7 внезапно нет"...

From:

livelight

В языке Си есть и активно используется куча всего такого, для чего не определено единое для всех платформ поведение. Например, int имеет такой размер, какой удобно платформе, что уже неприятно, если вдруг данные, которые вчера влезали, сегодня не влезают, не говоря уже о записи их на внешние устройства для чтения кем-нибудь. Элементы массива struct'ов компилятор может по своему желанию выровнять на границу слова. Аналогично - какой-нибудь long внутри struct, особенно если архитектура процессора не позволяет ему адресовать невыровненные слова. Учитывая обычные для Си операции вида "привести указатель к char* , прибавить сколько-то, откастовать полученное к другому типу указателя и что-нибудь сделать с полученным", простор для непереносимостей вообще гигантский. Так что - только java, только хардкор :)

From:

metaclass.livejournal.com

stdint.h спасет от всего.

From:

livelight

От выравниваний не спасёт :)
От разных endianness тоже, кстати.

И вот такой код

struct A {
whatever1 x;
whatever2 y;
whatever3 z;
} a[2];

write(fd, a, sizeof(a));

может нанести немало неожиданностей даже для типов whatever... из этой библиотеки.

From:

Даже в пределах одного x86 процессора не спасает, как только вступает в действие генерация кода с адресной арифметикой. Turbo C 2.0, модель памяти Huge. Я в ней писал и компилил ФИДО тоссер и мопутствующие ему программы, если что. ;-)

From:

Какой stdint.h в Turbo C 2.0? Насколько я помню, stdint.h появился в стандарте C99.

From:

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

From:

Ммм, вспомнил, что уже читал что-то Ваше на тему рулезности ~~хождения строем~~ простого и читаемого кода. Собственно, нет причин для спора.
Однако, мне действительно интересно, где в современном мире могут быть всерьез нужны фокусы с булевой арифметикой ? Навскидку приходят в голову только IP адреса и маски, потому что, на сколько я понимаю, сейчас даже контроллер осещения в "умном доме" тупо дешевле сделать на x64, под линуксом и, соответственно, с полным набором языков высокого уровня.

BTW, мб вспомним фидошные времена и перейдем на ты ?

From:

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

фокусы с булевой арифметикой
...
тупо дешевле сделать на x64, под линуксом и, соответственно, с полным набором языков высокого уровня.

То есть НЕ СЛЕДУЕТ ВООБЩЕ употреблять "данных низкого уровня" и обрабтку "низкого уровня" при написании программ (на любом языке, высокого ли уровня или нет - не важно)?

И, конечно же, написанный и откомпилированный сейчас код "на языке высокого уровня" никогда не нарвётся на то, что обрабатываемые им данные существенно изменились?

Умный дом? С автоапдейтящимися прошивками в железках, ога. Спасибо.
Через 5 лет, после смены таймзоны и апдейта прошивки под оную смену (например) - что будете делать (реальный случай - размер буфера под выдаваемой некоторой прошивкой текстовое представление времени оказался недостаточен при изменении наименования таймзоны, в результате - атака по переполнению стека и креш системы)? А что будет делать клиент, если автор программы "высокого уровня" в одном из контроллеров успел помереть?

Ах, ФИДО? См. bink plus и необходимость добавить 42 в одном месте в календарном расчёте в СТАНДАРТНОЙ библиотеке в 2000 году. Раскопано Киром Злобиным.

Runtime Error в паскалевских (дада, язык высокого уровня!) программах ДОС эпохе при запуске на достаточно быстрых процессорах.

Правда, зачем думать о низком уровне? Давайте писать на высоком и не думать вообще. :)

Edited Date: 2016-04-05 11:16 am (UTC)

From:

Вот вот - тут народ удивлялся почему в требования вакансии Win-программиста я прописал "умение работать на уровне Win32 API". Потому что нам этот программист нужен в основном на предмет низкоуровневые глюки в библиотеках и прочих фреймворках фиксить. На высоком уровне мы и сами могем.

Что касается Runtime Error 200 то это как раз проблема низкого уровня. Попала в комплект распространенного компилятора кривая ассемблерная библиотека с неудачно написанным кодом инициализации. Причем попала фактически в качестве учебного примера. Уровня совместимости с GW-Basic, которым при написании приличных программ пользоваться не следует. Возможно, поэтому борландовцы и не исправили вовремя - у них уже в 93-м был Turbo Vision, которым и рекомендовалось пользоваться ВМЕСТО Crt.

Существуют альтернативные библиотеки tpcrt и opcrt (из комплекта Turbo Professional и Object Professional соответственно), где этой проблемы нет. Я еще году в 95-м, когда Турбо Паскаль был основным моим рабочим языком, писал в юзнете что модуль CRT вреден и использование его - признак чайника.

From:

Проблема в "языке высокого уровня" как раз и состоит в том, что, оставаясь ТОЛЬКО на "высоком уровне", программист не имеет содержательной информации о том, какую библиотеку (из имеющихся вроде бы одинаковых) следует выбрать.

И потому выбирает "сердцем". :)

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

Собственно - так и пришлось в 2000 году патчить кусочек сишной библиотеки в bink+.

From:

>>тупо дешевле сделать на x64, под линуксом и, соответственно, с полным набором языков высокого уровня.

>То есть НЕ СЛЕДУЕТ ВООБЩЕ употреблять "данных низкого уровня" и обрабтку "низкого уровня" при написании программ (на любом языке, высокого ли уровня или нет - не важно)?

Где я это сказал ?
Я просил привести пример оправданного прменения булевой арифметики в современной программе.

> Умный дом? С автоапдейтящимися прошивками в железках, ога. Спасибо. Через 5 лет, после смены таймзоны и апдейта прошивки под оную смену (например) - что будете делать (реальный случай - размер буфера под выдаваемой некоторой прошивкой текстовое представление времени оказался недостаточен при изменении наименования таймзоны, в результате - атака по переполнению стека и креш системы)? А что будет делать клиент, если автор программы "высокого уровня" в одном из контроллеров успел помереть?

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

Но как это все связано с изначальным разговором про булеву арифметику, мне не очень понятно.

> Правда, зачем думать о низком уровне? Давайте писать на высоком и не думать вообще. :)
Ну, как бы, да. Мир к тому идет. В частности, Вашими усилиями. Нет ?

Edited Date: 2016-04-05 12:20 pm (UTC)

From:

оправданного прменения булевой арифметики в современной программе.

Почти любая реализация видеокодеков.
Содержательная обработка данных с конкретного железа.
При соответствующе документированном протоколе.

Edited Date: 2016-04-05 12:39 pm (UTC)

From:

Спасибо.
По дороге сам вспомнил про криптографию :-)

From:

besm6.livejournal.com

Во, я как раз хотел сказать.

Компактные сетевые протоколы с быстрым парсингом, кстати. Типа CBOR. Она там примитивная, но есть, и обеспечивает компактность.

Когда данных надо передать МНОГО, компактность протокола ой, важна...

From:

Если уж вспоминать про ФИДО - то лично я в своём тоссере ФИДО почты ВСЕ таблицы подписки линков на эхи храню побитно.

AreaLink[area_off] |= here_mask1;
AreaLink[area_off] &= here_mask0;
area_off - понятное дело, адрес байта. :)

From:

slobin.livejournal.com

Справедливости ради: не путаем "низкий (битовый) уровень" и "неопределённое поведение". Хотя, будем честны, спутать легко: и там, и там проблема на практике в том, что не слишком внимательный программист может просто не обратить внимание, что оно (2) не определено или (1) определено, но не так, как он наивно надеялся. Случай с 42 относился именно к "определено, но никто не прочитал определения".

И, кстати, конкретно эта засада единственно правильным способом не засажена в языке Ада (да-да, том самом): там есть ДВЕ операции `mod` и `rem`. Если их две, то ты невольно задумаешься, какая именно из них нужна. А если у тебя только `%`, который совпадает с одной из них, причём не с той -- вопрос имеет куда более высокие шансы быть проигнорированным.

... Маркс, Кейнс и кот Матроскин ...

From:

amarao-san.livejournal.com

Вот слабая типизация Си в этом вопросе меня всегда раздражала. Ведь никто и ничто не требует от компилятора автоматически приводить типы. Никакого runtime overhead'а или уменьшения возможности стрелять себе в ногу это не вызывает.

Почему бы не требовать ручной конвертации типов? Чтобы такое нельзя было:
unsigned int x=foo();
...
signed int y = x/2;

и т.д. Т.е. строгая типизация с правом typecast'инга как душе взбредёт. Но явным.

From:

Нормальные компилеры в случае такой фигни (неоднозначность интерпретации арифметической/логической ОПЕРАЦИИ) вроде как ругаются ворнингом.

Ну а на случай, если значение вписывается в unsigned, но не вписывается в signed или когда программист не подумал, что число помещенное в unsigned может быть отрицательным - тут уж он сам виноват. Хотя, конечно, незамеченное изменение спецификации API, которое будет замечено с меньшей вероятностью из-за отсутствия ворнингов при перекомпиляции - это неприятно.

From:

amarao-san.livejournal.com

Ну вот я не понимаю логику за "программист сам виноват", если добавление строгой типизации не ударит по райнтайму.

Нормальный подход (задним числом, спустя несколько десятилетий после создания языка) - сделать типизацию строгой.

То есть никакой конверции unsigned/signed. Хочешь конверсию - делай либо typecasting, либо пиши явно что делать.

Сколько бы при этом граблей прошло - словами не описать. А написать чуть больше union'ов - ни у кого бы руки не отвалились.

Заодно, кстати, и на int (x64) перешли бы по-человечески, потому что к этому моменту все бы точно знали из чего во что конвертят.

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

From:

хотя с
>(задним числом, спустя несколько десятилетий после создания языка) - сделать типизацию строгой.
наверняка было бы дофига головной боли,

мне ничего не остается, как согласиться с Вашими аргументами.

From:

livelight

После неявного приведения типов в плюсах, где строгости ради решили ограничиться одним неявным вызовом конструктора, и на том спасибо, а то ж могли и пятью -- конверсия между signed и unsigned - это вообще мелочи жизни :)

From:

yurikhan

Самый эпичный баг нестрогости системы типов в плюсах, который я сажал, был, когда я поменял тип одной переменной с int на int8_t.

int foo;
std::istringstream iss1("3");
iss1 >> foo; // foo == 3

int8_t bar;
std::istringstream iss2("3");
iss2 >> bar; // bar == 51

From:

livelight

Со вторым примером ситуация вообще другая.
Компилятор увидел, что оператора >> (int8_t &) не завезли, после чего сделал по сути вот такой код для вызова оператора >> (int &)

int8_t bar;
std::istringstream iss2("3");
int bar_replacement = (int)bar;
iss2 >> bar_replacement;

А в переменной bar осталось то, что осталось.

По-хорошему, за подмену ссылочного типа без явного каста компилятор должен бить по рукам гораздо сильнее, чем за подмену скалярного. А тут он сам занялся даже не просто подменой ссылочного типа, а подменой самой ссылки. Для оператора << это сошло бы с рук, а для >> вышло то, что вышло.

Edited Date: 2016-04-06 08:39 am (UTC)

From:

Нет, это не "что осталось", 51 это ASCII код цифры '3'.

From:

livelight

А, там внутре у него char был?
Тоже неплохо :)

From:

А что еще может быть внтуре у int8_t? В во всех попадавшихся мне реализациях языков C и C++ char это 8-битный integer, а 8-битный integer это char.

Ну то есть легенды о реализациях C, где char имеет размер 32 бита я слышал, но живьем никогда не видел.

From:

livelight

Насколько я помню, в стандарте большими буквами написано, что char - это ровно 1 байт, и если от этого отойти, то все стандартные способы работы с адресной арифметикой, используемые в гигабайтах уже написанного кода, полетят к чертям.
А вот какому-нибудь short short'у никто не запрещает тоже иметь размер 1 байт.

From:

В стандарте написано, что char - это минимальный квант адресации, что любые размеры типов кратны char, и результат sizeof выражается в char-ах. Но никто не обещал что этот квант равен 8 битам.

Существовали архитектуры, в которых минимальным адресуемым фрагментом было машинное слово. Там как ни крути, всегда получалось, что размер любого типа кратен размеру слова.

From:

livelight

Если минимальный квант адресации больше 8 бит, то тип int8_t получить вообще не получится, кроме как в битовых структурах. Но такое по указателю в operator >> точно не передашь никак.

From:

Только если искусственно ограничить использование значений превосходящих требуемый диапазон (как поступают с boolean).

From:

yurikhan

В идеале, int8_t был бы отдельным примитивным типом. Но в стандарте написано, что это typedef на какой-нибудь знаковый целочисленный тип на усмотрение реализации. В моей реализации — typedef signed char int8_t.

From:

По поводу того, как компилятор интерпретирует битовый сдвиг (если я все понимаю правильно и не отстал от жизни) - он тупо помещает левый и правый аргументы в регистры и генерит инструкцию shl/shr/sal/sar (в зависимости от знаковости типа ПЕРВОГО аргумента), оставляя undefined behaviour на совесть процессора.

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

Или Вы хотите, чтобы компилятор был умнее программиста и при каждом битовом сдвиге генерил инструкции проверки знака второго аргумента?

From:

yurikhan

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

if (foo < 0) {
    do_something();
}
bar << foo;

Если известно, что do_something() не бросает исключений, не завершает программу и не зацикливается, то компилятор имеет право объявить весь if мёртвым кодом и выоптимизировать.

From: